CAS Logowanie – Kompleksowy Przewodnik po Centralnym Systemie Uwierzytelniania

W dzisiejszym dynamicznym świecie cyfrowym, gdzie dostęp do niezliczonych aplikacji i usług jest codziennością, wyzwanie zarządzania wieloma loginami i hasłami staje się coraz bardziej uciążliwe. To właśnie w tym kontekście rozwiązania typu Single Sign-On (SSO) zyskują na znaczeniu, oferując użytkownikom wygodę, a administratorom bezpieczeństwo i uproszczenie zarządzania tożsamością. Jednym z najbardziej sprawdzonych i szeroko stosowanych systemów w tej kategorii jest Central Authentication Service (CAS). CAS logowanie to nie tylko techniczny proces, ale fundament bezpiecznej i efektywnej interakcji z zasobami cyfrowymi w wielu organizacjach, w szczególności w środowiskach akademickich i korporacyjnych.

Ten artykuł ma na celu kompleksowe przedstawienie systemu CAS, jego architektury, zasad działania, sposobów implementacji, a także kluczowych aspektów bezpieczeństwa i najlepszych praktyk. Dowiemy się, dlaczego CAS stał się standardem dla wielu instytucji i jak prawidłowo skonfigurować go, aby zapewnić zarówno wygodę użytkowania, jak i najwyższy poziom ochrony danych. Przyjrzymy się również wyzwaniom, z jakimi można się spotkać podczas wdrażania i utrzymania CAS, oraz porównamy go z innymi popularnymi rozwiązaniami SSO. Zrozumienie mechanizmów CAS logowania jest kluczowe dla każdego, kto zarządza infrastrukturą IT lub korzysta z usług wymagających uwierzytelnienia.

Co to jest CAS i jak działa mechanizm logowania?

Central Authentication Service (CAS), pierwotnie opracowany na Uniwersytecie Yale, to protokół oraz implementacja serwera służącego do scentralizowanego uwierzytelniania użytkowników. Jego głównym celem jest zapewnienie Single Sign-On (SSO), czyli możliwości zalogowania się raz i uzyskania dostępu do wielu niezależnych aplikacji bez konieczności ponownego wprowadzania danych uwierzytelniających. To fundamentalnie zmienia doświadczenie użytkownika, eliminując frustrację związaną z zarządzaniem wieloma zestawami poświadczeń, jednocześnie wzmacniając bezpieczeństwo poprzez scentralizowane zarządzanie tożsamością.

Architektura CAS opiera się na trzech kluczowych komponentach:

1. Użytkownik (User/Client): Osoba próbująca uzyskać dostęp do chronionej usługi.
2. Serwis/Aplikacja (Service/Application): Aplikacja internetowa, do której użytkownik chce się zalogować. Jest to tzw. „CAS client”.
3. Serwer CAS (CAS Server): Centralny serwer odpowiedzialny za uwierzytelnienie użytkownika i wydawanie biletów dostępu.

Mechanizm CAS logowania przebiega w kilku krokach:

1. Żądanie dostępu do chronionego zasobu: Użytkownik próbuje uzyskać dostęp do aplikacji (serwisu), która jest chroniona przez CAS.
2. Przekierowanie do serwera CAS: Aplikacja sprawdza, czy użytkownik posiada ważną sesję CAS. Jeśli nie, przekierowuje przeglądarkę użytkownika do serwera CAS, na stronę logowania (np. https://cas.example.com/cas/login?service=https://app.example.com/).
3. Uwierzytelnienie użytkownika: Użytkownik wprowadza swoje dane uwierzytelniające (login i hasło) na stronie serwera CAS. Serwer CAS weryfikuje te dane, np. wobec bazy LDAP, Active Directory, czy lokalnej bazy danych.
4. Wydanie Ticket Granting Ticket (TGT): Po pomyślnym uwierzytelnieniu, serwer CAS tworzy Ticket Granting Ticket (TGT), który jest przechowywany w sesji przeglądarki użytkownika w postaci cookie (zazwyczaj CASTGC). TGT jest dowodem na to, że użytkownik został uwierzytelniony przez serwer CAS.
5. Przekierowanie z powrotem do serwisu z Service Ticket (ST): Serwer CAS generuje unikalny, jednorazowy Service Ticket (ST) dla konkretnej żądanej aplikacji i przekierowuje przeglądarkę użytkownika z powrotem do tej aplikacji, dołączając ST jako parametr URL (np. https://app.example.com/?ticket=ST-xxxxxx).
6. Weryfikacja Service Ticket przez serwis: Aplikacja otrzymuje Service Ticket i wysyła go do serwera CAS w celu weryfikacji. Jest to połączenie typu back-channel (serwer-serwer), co oznacza, że ticket nie jest przesyłany bezpośrednio przez przeglądarkę użytkownika, co zwiększa bezpieczeństwo. Serwer CAS sprawdza ważność ST i odpowiada, czy ticket jest poprawny oraz zwraca identyfikator użytkownika.
7. Udzielenie dostępu do serwisu: Jeśli weryfikacja ST powiedzie się, aplikacja uznaje użytkownika za uwierzytelnionego i udziela mu dostępu do żądanego zasobu. Jednocześnie aplikacja tworzy własną sesję dla użytkownika.

Kluczową zaletą tego procesu jest to, że raz uwierzytelniony użytkownik (posiadający TGT) może uzyskać dostęp do innych aplikacji chronionych przez ten sam serwer CAS bez ponownego wprowadzania danych. Gdy użytkownik spróbuje uzyskać dostęp do nowej aplikacji, zostanie ponownie przekierowany do serwera CAS. Serwer CAS, widząc istniejący TGT, od razu wygeneruje nowy ST dla tej aplikacji i przekieruje użytkownika, pomijając stronę logowania. To jest właśnie istota Single Sign-On, którą zapewnia CAS logowanie.

Implementacja i konfiguracja CAS w środowisku produkcyjnym

Wdrożenie CAS w środowisku produkcyjnym wymaga starannego planowania i konfiguracji, aby zapewnić niezawodność, bezpieczeństwo i skalowalność. Proces ten zazwyczaj obejmuje instalację serwera CAS, integrację z istniejącymi systemami uwierzytelniania oraz konfigurację aplikacji klienckich.

Wybór i instalacja serwera CAS

Najpopularniejszą implementacją jest Apereo CAS (wcześniej Jasig CAS), rozwijany jako oprogramowanie open-source. Jest to aplikacja Java, którą można wdrożyć na serwerach aplikacji takich jak Apache Tomcat, Jetty czy WildFly. Standardowa instalacja obejmuje pobranie odpowiedniej wersji WAR (Web Application Archive) i umieszczenie go w kontenerze serwera aplikacji.

Przykładowy proces instalacji Apereo CAS na Tomcat:

1. Pobierz plik cas.war ze strony Apereo CAS (lub zbuduj ze źródeł).
2. Umieść cas.war w katalogu webapps serwera Tomcat.
3. Uruchom Tomcat. Serwer CAS powinien być dostępny pod adresem https://your-cas-server.com/cas.

Kluczowe jest, aby serwer CAS był dostępny wyłącznie przez HTTPS. Konfiguracja certyfikatów SSL/TLS jest absolutnie obowiązkowa, aby chronić dane uwierzytelniające przesyłane między przeglądarką użytkownika a serwerem CAS.

Integracja z systemami uwierzytelniania

Serwer CAS sam w sobie nie przechowuje danych użytkowników. Jego zadaniem jest delegowanie uwierzytelniania do zewnętrznych źródeł. Najczęściej integrowane systemy to:

• LDAP/Active Directory: Większość organizacji korporacyjnych i akademickich korzysta z tych katalogów. Konfiguracja CAS do współpracy z LDAP/AD polega na zdefiniowaniu parametrów połączenia (adres serwera, port, DN, filtr wyszukiwania użytkowników, atrybut hasła).
• Bazy danych SQL: Możliwe jest uwierzytelnianie użytkowników przechowywanych w bazach danych MySQL, PostgreSQL itp. Wymaga to konfiguracji sterowników JDBC i zdefiniowania zapytań SQL do weryfikacji danych.
• Wieloskładnikowe uwierzytelnianie (MFA/2FA): Apereo CAS wspiera integrację z różnymi dostawcami MFA (np. Duo Security, YubiKey, Google Authenticator), co znacznie podnosi poziom bezpieczeństwa.
• Inne protokoły: CAS może działać również jako proxy dla innych protokołów uwierzytelniania, takich jak SAML, OAuth/OIDC.

Przykładowa konfiguracja application.properties (lub cas.properties w starszych wersjach) dla LDAP:

cas.authn.ldap[0].ldapUrl=ldap://ldap.example.com:389
cas.authn.ldap[0].useSsl=true
cas.authn.ldap[0].baseDn=dc=example,dc=com
cas.authn.ldap[0].userFilter=sAMAccountName={user}
cas.authn.ldap[0].bindDn=cn=casbind,dc=example,dc=com
cas.authn.ldap[0].bindAction=AUTHENTICATE
cas.authn.ldap[0].searchFilter=cn={user}

Konfiguracja aplikacji klienckich (CAS Clients)

Każda aplikacja, która ma korzystać z CAS logowania, musi być skonfigurowana jako klient CAS. Istnieją biblioteki klienckie dla wielu języków programowania i frameworków (Java, PHP, Python, Ruby, .NET itp.), które upraszczają integrację. Konfiguracja klienta zazwyczaj wymaga podania adresu URL serwera CAS i adresu URL samej aplikacji (jako service).

Przykładowa konfiguracja klienta PHP (phpCAS):

require_once 'CAS.php';
phpCAS::client(CAS_VERSION_3_0, 'cas.example.com', 443, '/cas');
phpCAS::setNoCasServerValidation(); // Tylko do testów! W produkcji ustaw certyfikat CA.
phpCAS::setServiceURL('https://app.example.com/index.php');

if (!phpCAS::isAuthenticated()) {
    phpCAS::forceAuthentication();
}
echo 'Witaj, ' . phpCAS::getUser() . '!';

Niezwykle ważne jest również zarejestrowanie wszystkich serwisów w konfiguracji serwera CAS. Można to zrobić poprzez pliki konfiguracyjne (np. services/RegisteredService.json) lub przez interfejs administracyjny. Rejestracja serwisu określa, które aplikacje są uprawnione do otrzymywania biletów dostępu i na jakie adresy URL serwer CAS może przekierowywać użytkowników.

Przykład pliku services/Service-100.json:

{
  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "^(https|http)://(www.)?app.example.com/.*",
  "name" : "MyWebApp",
  "id" : 100,
  "description" : "Moja aplikacja webowa chroniona przez CAS.",
  "evaluationOrder" : 1
}

Prawidłowo zaimplementowane CAS logowanie, z uwzględnieniem tych kroków, zapewnia bezpieczne i sprawne środowisko Single Sign-On.

Bezpieczeństwo logowania CAS – kluczowe aspekty i zagrożenia

Bezpieczeństwo jest priorytetem w każdym systemie uwierzytelniania, a CAS logowanie, mimo swoich wbudowanych mechanizmów ochronnych, również wymaga uwagi. Poniżej przedstawiamy kluczowe aspekty bezpieczeństwa oraz potencjalne zagrożenia, na które należy zwrócić uwagę.

Obowiązkowe użycie HTTPS/SSL/TLS

To absolutna podstawa. Cała komunikacja między przeglądarką użytkownika a serwerem CAS, a także między aplikacjami klienckimi a serwerem CAS, musi odbywać się przez szyfrowane połączenie HTTPS. Bez tego, dane uwierzytelniające (login, hasło) oraz bilety dostępu (TGT, ST) byłyby przesyłane jako zwykły tekst, co czyniłoby je podatnymi na ataki typu Man-in-the-Middle (MITM) i podsłuch.

• Dla serwera CAS: Należy zainstalować ważny certyfikat SSL/TLS wystawiony przez zaufany urząd certyfikacji (CA).
• Dla aplikacji klienckich: Wszystkie aplikacje korzystające z CAS również powinny działać na HTTPS.
• Ważność certyfikatów: Regularne monitorowanie i odnawianie certyfikatów jest kluczowe, aby uniknąć przerw w działaniu i ostrzeżeń bezpieczeństwa dla użytkowników.

Ochrona przed typowymi atakami

1. Ataki Phishingowe: Strona logowania CAS jest centralnym punktem, co czyni ją atrakcyjnym celem dla phishingu.
   • Zabezpieczenie: Użytkownicy powinni być edukowani, aby zawsze sprawdzać adres URL strony logowania CAS. Można również dostosować wygląd strony logowania, aby zawierała unikalne elementy brandingowe organizacji, co ułatwi użytkownikom identyfikację autentycznej strony.
2. Przechwytywanie sesji (Session Hijacking): Jeśli sesja użytkownika (TGT cookie) zostanie skradziona, atakujący może uzyskać dostęp do wszystkich aplikacji, do których użytkownik był zalogowany.
   • Zabezpieczenie: CAS używa bezpiecznych ciasteczek (Secure i HttpOnly flags), aby zapobiec dostępowi do TGT przez skrypty po stronie klienta i wymusić przesyłanie tylko przez HTTPS. Krótki czas życia sesji TGT oraz regularne jej odnawianie również zmniejsza ryzyko.
3. Ataki typu Brute-Force i Słownikowe: Próby odgadnięcia hasła poprzez wielokrotne, automatyczne próby logowania.
   • Zabezpieczenie: CAS wspiera konfigurację polityk blokowania konta po określonej liczbie nieudanych prób logowania. Można również zintegrować CAPTCHA lub inne mechanizmy weryfikacji ludzkiej. Integracja z MFA dodatkowo utrudnia takie ataki.
4. Replay Attacks (ataki powtórzeniowe): Próba ponownego użycia wcześniej przechwyconego Service Ticket.
   • Zabezpieczenie: Service Tickets są jednorazowe i mają bardzo krótki czas ważności, co uniemożliwia ich ponowne użycie. Po walidacji przez serwis, ST jest natychmiast unieważniany przez serwer CAS.
5. Man-in-the-Middle (MITM) między serwisem a serwerem CAS: Choć rzadziej, możliwe są ataki na komunikację back-channel.
   • Zabezpieczenie: Również ta komunikacja powinna odbywać się przez HTTPS, a aplikacje klienckie powinny weryfikować certyfikat serwera CAS, aby upewnić się, że komunikują się z autentycznym serwerem.

Wieloskładnikowe Uwierzytelnianie (MFA/2FA)

Wdrożenie MFA to jeden z najskuteczniejszych sposobów na zwiększenie bezpieczeństwa CAS logowania. Nawet jeśli hasło zostanie skompromitowane, atakujący nadal potrzebuje drugiego czynnika (np. kodu z aplikacji, odcisku palca, klucza sprzętowego) do uzyskania dostępu. Apereo CAS oferuje szerokie możliwości integracji z popularnymi dostawcami MFA, co pozwala na dostosowanie poziomu bezpieczeństwa do potrzeb organizacji.

Audyt i logowanie

Prawidłowe logowanie zdarzeń na serwerze CAS jest niezbędne do monitorowania bezpieczeństwa i wykrywania podejrzanych aktywności. Logi powinny zawierać informacje o pomyślnych i nieudanych próbach logowania, adresach IP, nazwach użytkowników, statusach biletów. Regularna analiza tych logów pozwala szybko reagować na potencjalne zagrożenia.

Regularne aktualizacje

Zarówno serwer CAS, jak i biblioteki klienckie powinny być regularnie aktualizowane do najnowszych wersji. Twórcy Apereo CAS nieustannie wprowadzają poprawki bezpieczeństwa i nowe funkcje, a pozostawanie przy przestarzałej wersji może narazić system na znane już luki bezpieczeństwa.

Podsumowując, chociaż CAS logowanie zapewnia solidne podstawy bezpieczeństwa, wymaga aktywnego zarządzania i ciągłej uwagi, aby skutecznie chronić tożsamości użytkowników i zasoby organizacji.

Konfiguracja i zarządzanie serwerem CAS – zaawansowane aspekty

Zarządzanie serwerem CAS to proces, który wykracza poza początkową instalację i integrację. Obejmuje szereg zaawansowanych konfiguracji, które pozwalają dostosować system do specyficznych wymagań, zwiększyć jego wydajność, elastyczność i użyteczność. Poniżej przedstawiamy kluczowe obszary w tym zakresie.

Konfiguracja obsługi uwierzytelniania (Authentication Handlers)

Centralnym elementem CAS jest elastyczność w sposobie weryfikacji tożsamości użytkowników. Można skonfigurować wiele źródeł uwierzytelniania, a CAS będzie je próbował w określonej kolejności. Najczęściej spotykane konfiguracje to:

• LdapAuthenticationHandler: Dla uwierzytelniania przeciwko serwerom LDAP lub Active Directory. Pozwala na konfigurację wielu parametrów, takich jak:
  • ldapUrl: Adres serwera LDAP.
  • baseDn: Podstawowa ścieżka wyszukiwania użytkowników.
  • userFilter: Filtr do wyszukiwania użytkownika (np. (uid={user}) dla LDAP, (sAMAccountName={user}) dla AD).
  • bindDn i bindCredential: Dane konta serwisowego do przeszukiwania katalogu (ważne dla bezpieczeństwa).
• JdbcAuthenticationHandler: Do uwierzytelniania wobec baz danych SQL. Wymaga definicji zapytań SQL do znalezienia użytkownika i weryfikacji hasła (np. SELECT password FROM users WHERE username=?).
• AcceptUsersAuthenticationHandler: Prosty handler do testowania, który przyjmuje z góry zdefiniowaną listę loginów i haseł (niezalecany do środowisk produkcyjnych).
• MultifactorAuthenticationHandler: Integracja z rozwiązaniami MFA.

Można również zdefiniować polityki haseł, takie jak minimalna długość, złożoność, czy wymuszenie zmiany hasła, które będą egzekwowane przez CAS lub delegowane do zewnętrznego systemu.

Zarządzanie usługami (Service Registry)

Serwer CAS musi wiedzieć, które aplikacje są uprawnione do korzystania z jego usług. Odbywa się to poprzez rejestrację serwisów. Każdy zarejestrowany serwis definiuje:

• serviceId: Wyrażenie regularne (regex) pasujące do adresów URL aplikacji, które mogą korzystać z CAS (np. ^(https|http)://(www.)?my-app.com/.*).

  Jest to niezwykle ważne dla bezpieczeństwa, ponieważ zapobiega wyłudzaniu biletów przez nieautoryzowane strony.

• name i description: Nazwa i opis serwisu, pomocne w zarządzaniu.
• id: Unikalny identyfikator serwisu.
• evaluationOrder: Kolejność oceny, jeśli wiele reguł może pasować.

Rejestracja serwisów może być zarządzana za pomocą plików JSON/YAML (najczęściej w katalogu etc/cas/services) lub poprzez bazę danych (np. za pomocą modułu JPA Service Registry) dla bardziej dynamicznego zarządzania. Zaawansowane opcje obejmują również konfigurację atrybutów użytkowników, które mają być zwracane do serwisu (np. imię, nazwisko, adres e-mail) po pomyślnym CAS logowaniu.

Dostosowanie interfejsu użytkownika (User Interface Customization)

Strona logowania CAS jest punktem styku z użytkownikiem, dlatego ważne jest, aby była spójna z brandingiem organizacji. Apereo CAS pozwala na łatwe dostosowanie wyglądu:

• Zmiana logo, kolorów, stylów CSS.
• Dodawanie niestandardowych elementów HTML (np. linków do pomocy, polityki prywatności).
• Dostosowanie komunikatów o błędach.
• Obsługa wielu języków (i18n).

Dostosowania te są zazwyczaj realizowane poprzez modyfikację plików szablonów (Thymeleaf) i plików CSS znajdujących się w strukturze projektu CAS.

Polityki wygasania biletów i sesji

Zarządzanie czasem życia biletów i sesji jest kluczowe dla bezpieczeństwa i wydajności:

• Ticket Granting Ticket (TGT): Czas życia TGT (np. 8 godzin) definiuje, jak długo użytkownik może korzystać z SSO bez ponownego logowania. Zbyt długi czas zwiększa ryzyko przechwycenia sesji, zbyt krótki – obniża wygodę.
• Service Ticket (ST): ST są jednorazowe i mają bardzo krótki czas życia (kilka sekund), ponieważ są natychmiastowo walidowane i unieważniane.

Konfiguracja tych polityk odbywa się w plikach konfiguracyjnych serwera CAS (application.properties).

Monitorowanie i diagnostyka

Skuteczne zarządzanie wymaga monitorowania stanu serwera CAS. Apereo CAS, jako aplikacja Java, może być monitorowany za pomocą standardowych narzędzi JMX. Dodatkowo, szczegółowe logi zdarzeń (log4j2) dostarczają informacji o próbach logowania, błędach uwierzytelniania, wydawaniu biletów itp. Integracja z systemami monitorowania (np. Prometheus, Grafana) pozwala na bieżące śledzenie wydajności i wykrywanie anomalii.

Zaawansowana konfiguracja i proaktywne zarządzanie tymi aspektami sprawiają, że CAS logowanie staje się robustnym i bezpiecznym elementem infrastruktury IT, spełniającym wymagania nawet najbardziej złożonych środowisk.

Wyzwania i najlepsze praktyki w logowaniu CAS

Choć CAS logowanie oferuje znaczące korzyści, jego wdrożenie i utrzymanie wiążą się z pewnymi wyzwaniami. Poznanie tych trudności oraz stosowanie najlepszych praktyk pozwala na maksymalizację korzyści i minimalizację ryzyka.

Typowe wyzwania

1. Złożoność początkowej konfiguracji: Proces instalacji i konfiguracji serwera CAS, zwłaszcza w połączeniu z różnymi źródłami uwierzytelniania (np. LDAP z SSL/TLS), może być skomplikowany i czasochłonny. Wymaga specjalistycznej wiedzy z zakresu Java, serwerów aplikacji, bezpieczeństwa sieci i protokołów uwierzytelniania.
2. Wymagania dotyczące infrastruktury: CAS wymaga dedykowanego serwera (lub klastra serwerów) i odpowiedniej konfiguracji sieciowej (firewall, load balancer), aby zapewnić wysoką dostępność i wydajność, szczególnie w dużych środowiskach.
3. Integracja z istniejącymi aplikacjami: Adaptacja legacy aplikacji do korzystania z CAS może być trudna, zwłaszcza jeśli nie są zgodne ze standardowymi protokołami webowymi lub nie posiadają dostępnych bibliotek klienckich.
4. Zarządzanie certyfikatami SSL/TLS: Prawidłowe zarządzanie certyfikatami (generowanie, instalacja, odnawianie) jest krytyczne dla bezpieczeństwa, ale może być źródłem błędów i przestojów, jeśli nie jest odpowiednio nadzorowane.
5. Szkolenie użytkowników: Nawet prosty system SSO wymaga poinformowania użytkowników o nowym sposobie logowania, zasadach bezpieczeństwa (np. rozpoznawanie strony logowania) i procedurach pomocy technicznej.
6. Skalowalność i wydajność: W bardzo dużych środowiskach (tysiące jednoczesnych logowań), serwer CAS może wymagać zaawansowanej konfiguracji klastrowej i optymalizacji, aby uniknąć wąskich gardeł.

Najlepsze praktyki w logowaniu CAS

1. Używaj oficjalnych bibliotek klienckich i zaleceń Apereo CAS: Oficjalne biblioteki są dobrze przetestowane, bezpieczne i zgodne z najnowszymi standardami protokołu CAS. Unikaj własnoręcznych implementacji, chyba że jest to absolutnie konieczne i masz głęboką wiedzę na temat protokołu i bezpieczeństwa.
2. Zawsze używaj HTTPS dla całej komunikacji: To jest fundament bezpieczeństwa. Upewnij się, że serwer CAS, wszystkie aplikacje klienckie i komunikacja back-channel (serwer-serwer) używają ważnych certyfikatów SSL/TLS.
3. Implementuj Wieloskładnikowe Uwierzytelnianie (MFA): Zwiększ bezpieczeństwo, dodając drugi czynnik weryfikacji tożsamości. Apereo CAS ma wbudowane wsparcie dla wielu dostawców MFA, co ułatwia wdrożenie.
4. Regularnie aktualizuj serwer CAS i klientów: Bądź na bieżąco z najnowszymi wersjami Apereo CAS, aby korzystać z poprawek bezpieczeństwa, nowych funkcji i ulepszeń wydajności. Pamiętaj o testowaniu aktualizacji w środowisku deweloperskim przed wdrożeniem na produkcję.
5. Monitoruj i loguj zdarzenia: Skonfiguruj szczegółowe logowanie na serwerze CAS. Monitoruj logi pod kątem nieudanych prób logowania, nietypowych aktywności i błędów. Użyj narzędzi do agregacji i analizy logów.
6. Stosuj silne polityki haseł i blokady kont: Wymuszaj złożone hasła, regularne zmiany i blokowanie kont po kilku nieudanych próbach logowania.
7. Dokładnie rejestruj serwisy
   

   Powiązane wpisy:

   1. Wprowadzenie do bankowości cyfrowej: Rewolucja „ING Bank online”