Z punktu widzenia użytkowników warto na bieżąco śledzić doniesienia na ten temat i weryfikować, czy nasze dane nie zostały ujawnione w tego typu incydentach. Jednak skuteczną weryfikację w tym zakresie jest w stanie wykonać tylko niewielka część użytkowników. W szczególności osoby nietechniczne prawdopodobnie rzadko będą miały w ogóle świadomość potrzeby wykonania takiej weryfikacji. Z tego względu warto wyręczyć użytkowników naszego systemu i wykorzystać dostępne informacje o wyciekach do zwiększenia bezpieczeństwa kont w naszych systemach. Tego typu podejście rekomendują organizacje takie jak NIST, czy OWASP.
Jedna z rekomendacji NIST, dokładniej [dokument SP 800-63B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf), zaleca sprawdzanie haseł użytkowników pod kątem ich występowania w bazach pochodzących z wycieków. Podobne wytyczne zawiera również [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/), czyli standard dotyczący zabezpieczania i testowania aplikacji webowych. W aktualnej wersji 4.0.2 wytyczne te znajdziemy w sekcji V2.1 Password Security Requirements w punkcie 2.1.7. Poniżej fragmenty dokumentów, kolejno NIST, OWASP ASVS.
Obie rekomendacje sprowadzają się do sprawdzania, czy hasła wykorzystywane przez użytkowników nie wyciekły już wcześniej w ramach różnego rodzaju incydentów bezpieczeństwa. Niestety przez cały czas częstą praktyką jest wykorzystywanie przez użytkowników tych samych haseł w kilku różnych systemach. W takiej sytuacji choćby jeżeli hasło jest odpowiednio złożone i spełnia naszą politykę haseł, to można przyjąć, iż jest „spalone” i znane potencjalnym atakującym, a co za tym idzie, nie może pełnić swojej roli.
### Jak sprawdzić jakie hasła wyciekły i skąd pobrać ich listę?
Do weryfikacji haseł pod kątem ich obecności w danych z wycieków można wykorzystać serwis [Have I Been Pwned](https://haveibeenpwned.com/), w szczególności udostępnioną przez ten serwis listę ponad 300 milionów haseł. O tym serwisie pisałam już artykule pt. [Silne hasła i użyteczność haseł - w jaki sposób hasła są łamane i jakie hasła są bezpieczne?](https://www.sages.pl/blog/silne-hasla-i-uzytecznosc-hasel-w-jaki-sposob-hasla-sa-lamane-i-jakie-hasla-sa-bezpieczne).
Hasła udostępnione są w postaci skrótów SHA1 m.in. po to, aby plik nie stanowił listy haseł do ataków słownikowych. Do weryfikacji bywają również wykorzystywane krótsze listy najczęściej wykorzystywanych haseł, które są przygotowywane właśnie na podstawie haseł ze znanych wycieków. Wykorzystanie list zawierających 1 000, czy 10 000 najczęściej wykorzystywanych haseł jest zgodne z dokładną rekomendacją OWASP ASVS. Do tej listy warto wybrać tylko hasła zgodne z polityką haseł. Słabsze hasła i tak nie mogłyby zostać wykorzystane w naszym systemie. Listy haseł można znaleźć na przykład [tutaj](https://github.com/danielmiessler/SecLists/tree/master/Passwords). Do listy warto również dodać wyrazy specyficzne dla systemu, na przykład nazwa systemu, login użytkownika, imię i nazwisko użytkownika, czy ich kombinacje.
Z oczywistych względów bezpieczniejszym rozwiązaniem będzie porównywanie haseł z jak największą listą. Dochodzą tutaj jeszcze kwestie użyteczności i reakcji użytkowników np. na niedopuszczenie przez system kilku różnych propozycji haseł. Przy dobrej implementacji choćby pełna lista 300 milionów haseł nie powinna znacząco pogarszać wydajności systemu, niemniej jednak jest to bardziej wymagające niż w przypadku kilkunastu tysięcy haseł. Wydajna implementacja może być po prostu bardziej czasochłonna dla programistów.
Sprawdzenie warto wykonywać podczas tworzenia konta na etapie rejestracji, zmiany hasła i ewentualnie przy pierwszym logowaniu od wprowadzenia zabezpieczenia lub aktualizacji listy haseł z wycieków.
### Jak informować użytkownika o przyczynie odrzucenia hasła?
Zgodnie z rekomendacją NIST w momencie odrzucenia „spalonego” hasła warto, aby aplikacja informowała o przyczynie, czyli o obecności takiego hasła na liście prostych haseł, czy haseł, które wyciekły z innych systemów. Z uwagi na użytkowników nietechnicznych warto poinformować o tym fakcie w przystępny sposób, np. dodając odniesienie do dokładniejszego wyjaśnienia, czym są listy haseł z wycieków. Przykładem może być zamieszczony w dalszej części artykułu zrzut ekranu z weryfikacji haseł wykonanych przez Google.
### Weryfikacja haseł z punktu widzenia użytkowników
Wracając do kwestii sprawdzania haseł samodzielnie przez użytkowników tutaj również przydatny jest serwis Have I Been Pwned. W serwisie wyszukiwać możemy po naszym adresie e-mail oraz numerze telefonu. Serwis umożliwia również ustawienie powiadomienia, w przypadku pojawienia się naszego adresu e-mail w danych pochodzących z kolejnych wycieków. jeżeli otrzymamy powiadomienie i sprawdzimy, iż w zakresie ujawnionych danych są hasła, będziemy wiedzieli, iż hasło należy natychmiast zmienić.
Poniżej przykładowy screen z przykładowymi wynikami sprawdzenia konta w serwisie dla adresu e-mail.
Wynik zawiera krótką informację o incydencie wraz z listą danych, które zostały ujawnione, w moim przykładzie są to E-mail addresses, Geographic locations, IP addresses, Names, Passwords. Serwis Have I Been Pwned jest znany w społeczności bezpieczeństwa i uznawany za zaufany, jednak warto pamiętać, aby do wszystkich serwisów reklamujących się, jako pozwalające na sprawdzenie bezpieczeństwa haseł podchodzić z ostrożnością i nie podawać w nich swoich haseł, przykładem może być ten [atak](https://arstechnica.com/information-technology/2012/12/how-script-kiddies-can-hijack-your-browser-to-steal-your-password/).
Przykładem zastosowania mechanizmu weryfikacji haseł pod kątem ich wycieku jest przeglądarka Chrome, która pozwala na sprawdzenie bezpieczeństwa zapisanych haseł. Chrome sprawdza również, czy hasła są odpowiednio silne (złożone). Taką weryfikację można wykonać, np. sprawdzając poziom bezpieczeństwa konta Google lub bezpośrednio w przeglądarce wybierając opcję sprawdzenia haseł w ustawieniach.
Kwestia bezpieczeństwa zapisywania haseł w przeglądarce to już temat na inny artykuł ☺. Generalnie nie rekomenduję zapisywania w przeglądarce haseł do ważnych dla nas systemów np. konta w serwisach społecznościowych, ale w przypadku systemów mniej ważnych, gdzie nie ma możliwości modyfikacji istotnych danych, czy podejrzenia danych wrażliwych, może się to okazać wygodnym rozwiązaniem.
Na poniższym zrzucie ekranu przykładowy wynik takiego sprawdzenia dla zapisanych kilku słabych haseł.
### Podsumowanie
Na koniec podsumujmy kilka najważniejszych zasad dotyczących bezpieczeństwa haseł, zarówno z punktu widzenia użytkownika jak i właściciela aplikacji.
**Najważniejsze zasady bezpieczeństwa haseł dla użytkownika**:
* Nie stosujemy takich samych haseł (lub haseł bardzo podobnych) do różnych aplikacji.
* Regularnie sprawdzamy, czy nasze hasło nie wyciekło (np. z wykorzystaniem powiadomień w serwisie Have I Been Pwned).
* W systemach, które dają taką możliwość, włączamy logowanie wieloskładnikowe, czyli tzw. 2FA/MFA.
* Stosujemy silne (złożone) hasła, które zapamiętujemy lub zapisujemy w managerze haseł (np. KeePass).
**Najważniejsze zasady bezpieczeństwa haseł dla właściciela aplikacji**:
* Wprowadzenie polityki haseł (wymagania na długość hasła oraz jego złożoność) i funkcjonalności sprawdzenia siły hasła.
* Umożliwienie logowania wieloskładnikowego, czyli tzw. 2FA/MFA.
* Weryfikacja, czy hasło nie znajduje się na liście najsłabszych haseł oraz haseł z wycieków.
* Wprowadzenie ochrony przed atakami automatycznymi w postaci dodawania kilkusekundowych odstępów pomiędzy kolejnymi logowaniami oraz blokowania konta lub też spowalniania logowania w przypadku wykrycia kilku następujących po sobie nieudanych prób logowania.
* Uniemożliwienie wylistowania loginów użytkowników aplikacji.
