Polityka haseł w Państwa organizacji może nadal wymagać wielkiej litery, symbolu i zmiany co 90 dni. Amerykański National Institute of Standards and Technology (NIST) odszedł od wszystkich trzech wymogów. Jego aktualne wytyczne, SP 800-63B-4, zostały sfinalizowane w 2025 roku i zastępują wydanie SP 800-63B z 2020 roku.
NIST pisze te wytyczne dla amerykańskich systemów federalnych, ale są one przydatnym punktem odniesienia dla każdej organizacji. Poniżej opisujemy, co zawierają i jak je stosować.
Zasady dotyczące haseł w SP 800-63B-4
Sekcja 3.1.1.2 określa wymagania dla systemów weryfikujących hasła. NIST używa słowa SHALL dla wymagań (musi) i SHOULD dla zaleceń (powinien).
| Zagadnienie | Co mówi NIST |
|---|---|
| Minimalna długość, gdy hasło jest jedynym składnikiem | SHALL: co najmniej 15 znaków |
| Minimalna długość, gdy hasło jest częścią MFA | SHALL: co najmniej 8 znaków |
| Maksymalna długość | SHOULD: dopuszczać co najmniej 64 znaki |
| Znaki | SHOULD: akceptować wszystkie drukowalne znaki ASCII, spacje i Unicode |
| Reguły złożoności | SHALL NOT: nie wolno ich narzucać, np. „jedna wielka litera, jedna cyfra, jeden symbol” |
| Okresowa zmiana | SHALL NOT: nie wolno jej wymagać |
| Potwierdzone ujawnienie | SHALL: wymusić zmianę, gdy są dowody, że hasło zostało ujawnione |
| Lista zablokowanych haseł | SHALL: sprawdzać nowe hasła pod kątem popularnych, przewidywalnych lub ujawnionych wartości |
| Podpowiedzi i pytania bezpieczeństwa | SHALL NOT: nie wolno przechowywać podpowiedzi ani zadawać pytań opartych na wiedzy |
| Menedżery haseł | SHALL: dopuszczać je i autouzupełnianie; SHOULD: dopuszczać wklejanie |
| Nieudane próby | SHALL: ograniczać ich liczbę |
| Obcinanie | SHALL: sprawdzać całe wpisane hasło |
Dlaczego stare zasady odeszły
Reguły złożoności i wymuszana zmiana haseł sprawiają wrażenie rygorystycznych, ale skłaniają ludzi do przewidywalnych schematów. Użytkownik zmuszony do zmiany hasła Autumn2026! (jesień) może wybrać Winter2026! (zima), a atakujący znający stare hasło odgadnie nowe.
NIST stawia zamiast tego na długość i listę zablokowanych haseł. Długą frazę hasłową łatwiej zapamiętać niż krótki losowy ciąg znaków. Zmiana hasła pomaga dopiero wtedy, gdy hasło wyciekło, dlatego NIST wiąże ją z dowodami ujawnienia, a nie z kalendarzem.
To lista zablokowanych haseł zastępuje reguły złożoności jako rzeczywisty filtr. Odrzuca hasła, które atakujący próbują w pierwszej kolejności: popularne wybory, słowa związane z organizacją i hasła, które już pojawiły się w wyciekach.
Sprawdzanie haseł z wycieków
Usługa „Pwned Passwords” serwisu Have I Been Pwned pozwala sprawdzić hasło w danych z wycieków bez wysyłania hasła. System oblicza skrót hasła algorytmem SHA-1 i wysyła tylko pierwsze pięć znaków skrótu. Usługa zwraca wszystkie końcówki skrótów zaczynających się od tych pięciu znaków, wraz z liczbą wystąpień, a porównanie odbywa się lokalnie.
# SHA-1 of "password" is 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
curl -s -H "Add-Padding: true" https://api.pwnedpasswords.com/range/5BAA6Dzięki temu podejściu, zwanemu k-anonimowością, usługa nigdy nie dowiaduje się, które hasło zostało sprawdzone. Typowa odpowiedź zawiera kilkaset końcówek, a nagłówek Add-Padding ukrywa rzeczywisty rozmiar odpowiedzi przed każdym, kto obserwuje ruch. Wyszukiwanie zakresu haseł nie wymaga klucza API.
To sprawdzenie warto wbudować w ekrany ustawiania i zmiany hasła. W środowiskach Active Directory warto przyjrzeć się narzędziom, które stosują listę haseł z wycieków przy zmianach haseł domenowych.
Pozwolić ludziom korzystać z menedżerów haseł
NIST wymaga, aby systemy weryfikujące dopuszczały menedżery haseł i autouzupełnianie. To ma sens: menedżer sprawia, że długie, unikalne hasła stają się praktyczne, i wypełnia je tylko w domenie, dla której hasło zostało zapisane. Blokowanie wklejania w formularzach logowania działa przeciwko temu.
Pracownikom warto zapewnić firmowy menedżer haseł, zamiast zostawiać im wybór. Sam menedżer należy chronić silną frazą główną i uwierzytelnianiem wieloskładnikowym odpornym na phishing.
Nie każde MFA jest takie samo
Przy drugim składniku samo skradzione hasło już nie wystarcza, ale niektóre metody nadal są podatne na phishing. Fałszywa strona logowania atakującego może poprosić o kod i przekazać go dalej w czasie rzeczywistym. NIST definiuje odporność na phishing jako zdolność protokołu do zapobiegania ujawnieniu sekretów bez polegania na czujności użytkownika.
| Metoda | Odporna na phishing? | Uwagi NIST |
|---|---|---|
| Kod SMS lub głosowy | Nie | Uwierzytelniacz „o ograniczonym zastosowaniu”; systemy weryfikujące muszą oferować alternatywy i powinny wykrywać podmianę karty SIM i przeniesienie numeru |
| Kod z aplikacji uwierzytelniającej (TOTP) | Nie | Kody są wpisywane ręcznie, więc można je przekazać dalej |
| Zatwierdzenie push lub aplikacja pozapasmowa | Nie | Metody pozapasmowe nie są odporne na phishing |
| Kod lub link e-mail | Niedozwolone jako metoda pozapasmowa | E-mail SHALL NOT: nie wolno go używać do uwierzytelniania pozapasmowego |
| Klucz bezpieczeństwa FIDO2 / WebAuthn lub klucz dostępu (passkey) | Tak | Odpowiedź jest powiązana ze zweryfikowaną nazwą strony |
Na środkowym poziomie pewności NIST, AAL2, systemy weryfikujące SHALL (muszą) oferować co najmniej jedną opcję odporną na phishing. Na najwyższym poziomie, AAL3, uwierzytelniacz musi zapewniać odporność na phishing i używać klucza prywatnego, którego nie da się wyeksportować.
Klucze dostępu (passkeys)
Klucz dostępu (passkey) to poświadczenie FIDO oparte na WebAuthn. Urządzenie tworzy parę kluczy dla każdej strony. Strona przechowuje tylko klucz publiczny, a klucz prywatny pozostaje u użytkownika. Odblokowuje się go tą samą metodą co urządzenie, np. odciskiem palca, rozpoznawaniem twarzy lub kodem PIN. FIDO Alliance zaznacza, że dane biometryczne pozostają na urządzeniu i nigdy nie są wysyłane do strony.
Ponieważ każdy klucz dostępu jest powiązany z jedną stroną, po prostu nie zadziała w łudząco podobnej domenie phishingowej. Na serwerze nie ma też wspólnego sekretu, który można by wykraść.
Klucze dostępu występują w dwóch postaciach:
- Synchronizowane klucze dostępu są kopiowane między urządzeniami za pośrednictwem usługi synchronizacji dostawcy. NIST nazywa je uwierzytelniaczami synchronizowanymi i dopuszcza je na poziomie AAL2. Ponieważ klucz można wyeksportować, SHALL NOT: nie wolno ich używać na poziomie AAL3.
- Klucze dostępu powiązane z urządzeniem pozostają na jednym urządzeniu, np. sprzętowym kluczu bezpieczeństwa. Sprawdzają się w przypadku administratorów i innych kont wysokiego ryzyka.
Trzeba też pomyśleć o odzyskiwaniu konta. Jeśli konto chronione kluczem dostępu można zresetować linkiem e-mail lub telefonem do helpdesku, atakujący po prostu wybiorą tę drogę. Odzyskiwanie konta powinno być co najmniej tak silne jak logowanie, które zastępuje.
Polityka do przyjęcia
- Minimum 15 znaków, gdy hasło jest jedynym składnikiem, i dopuszczenie co najmniej 64.
- Brak reguł złożoności i brak okresowego wygasania haseł.
- Sprawdzanie każdego nowego hasła na liście haseł z wycieków i popularnych haseł.
- Wymuszanie zmiany tylko w razie dowodów ujawnienia.
- Zapewnienie menedżera haseł oraz dopuszczenie wklejania i autouzupełniania.
- Wymaganie MFA wszędzie, gdzie jest dostępne, oraz MFA odpornego na phishing dla administratorów, poczty i zdalnego dostępu.
- Wdrażanie kluczy dostępu tam, gdzie obsługują je systemy, zaczynając od kont wysokiego ryzyka.
- Ograniczanie liczby nieudanych logowań i zapewnienie, że odzyskiwanie konta jest tak silne jak logowanie.
Od czego zacząć
Czy hasło pojawiło się już w danych z wycieków, można sprawdzić naszym narzędziem sprawdzania wycieku hasła, a jak długa powinna być fraza hasłowa – w naszym generatorze haseł.
Jeśli przebudowują Państwo politykę tożsamości lub planują wdrożenie kluczy dostępu, nasz zespół doradczy pomoże to zaplanować.
