Co naprawdę powinna mówić nasza polityka haseł?

Dlaczego stare zasady były błędne

Zasady dotyczące haseł, które nadal obowiązują w większości firm, były rozsądnie brzmiącymi domysłami z czasów, gdy było mniej danych. Wymóg zupy ze znaków i reset co 90 dni nie wynikały ze złej woli; to była teoria o działaniu napastników, która okazała się odwrotna do rzeczywistości. Gdy badacze i krajowe instytucje przeanalizowały realne zachowania ludzi i realne dane o naruszeniach, obie zasady zostały wycofane.

Wymuszona złożoność dawała słabe, przewidywalne hasła

Idea stojąca za regułami składu była taka, że wymaganie wielkiej litery, małej litery, cyfry i symbolu wymusi większą, trudniejszą do odgadnięcia przestrzeń haseł. W praktyce zamknęło to ludzi w małym zbiorze przewidywalnych wzorców. Reguła mówiąca „dodaj wielką literę, cyfrę i symbol" niezmiennie produkuje Password1!, Summer2026! i Company123$, bo to droga najmniejszego oporu dla człowieka, który musi to zapamiętać.

Napastnicy znają te wzorce. Narzędzia do łamania haseł w pierwszej kolejności stosują dokładnie te same transformacje: zamiana pierwszej litery na wielką, dopisanie roku, zamiana „a" na „@", dodanie „!" na końcu. W efekcie reguła, która miała poszerzyć przestrzeń poszukiwań, zawęziła ją do wzorców, które sama przewiduje. Wytyczne NIST Rev. 4 wprost stwierdzają, że weryfikatorom „nie wolno narzucać innych reguł składu (na przykład wymagania mieszania różnych typów znaków) dla haseł", i wyjaśniają to uzasadnienie w załączniku dotyczącym siły haseł. NCSC jest bardziej dosadny: wymogi złożoności „nie zapewniają żadnej obrony przed typowymi rodzajami ataków" i nie powinny być stosowane.

Wymuszony reset co 90 dni sprawiał, że ludzie wybierali gorsze hasła

Okresowe wygasanie zakładało, że regularna zmiana hasła ogranicza szkody wynikające z cichej kradzieży. Zachowanie, które to faktycznie wywoływało, podcinało to założenie. Kiedy ludzie muszą zmieniać hasło co 90 dni, nie wymyślają za każdym razem nowego, silnego, niepowiązanego hasła. Wprowadzają najmniejszą zmianę, jaką zaakceptuje system: Spring2026 staje się Summer2026, potem Autumn2026; Welcome1 staje się Welcome2. Nowe hasło to trywialny przyrost starego, który napastnik znający stare hasło odgadnie w kilka sekund.

Wymuszona rotacja skłania też ludzi do zapisywania haseł w niebezpiecznych miejscach i ponownego używania tego samego rdzenia w różnych systemach, bo zapamiętywanie rotującego zestawu jest naprawdę trudne. NIST wymaga dziś odwrotnego domyślnego podejścia: nie wymuszaj rutynowych zmian i wymuszaj zmianę tylko przy dowodach na przejęcie. Wytyczne NCSC zgadzają się, że regularne wygasanie „szkodzi bardziej, niż pomaga", i zalecają zmianę hasła tylko wtedy, gdy wiadomo albo podejrzewa się, że zostało przejęte. Ta zmiana nie jest rozluźnieniem bezpieczeństwa. Usuwa regułę, która uczyła użytkowników wybierać słabsze sekrety.

Co mówi współczesny standard

Aktualne wytyczne NIST i NCSC zbiegają się w mały, spójny zestaw zasad. Zmiana polega na przejściu od reguł pilnujących kształtu hasła do reguł blokujących znane złe hasła i pozwalających używać długich. Poniżej znajdziesz to, czego wymagają standardy, wraz z techniczną logiką stojącą za każdą linijką.

Długość zamiast złożoności

Długość to cecha, która najbardziej niezawodnie opiera się zgadywaniu i łamaniu, bo każdy dodatkowy znak mnoży pracę, jaką musi wykonać napastnik. NIST SP 800-63B Rev. 4 ustala minimum: hasło używane jako pojedynczy czynnik musi mieć co najmniej 15 znaków, a hasło używane wyłącznie w ramach uwierzytelniania wieloskładnikowego może być krótsze, ale musi mieć co najmniej 8 znaków. Maksimum powinno wynosić co najmniej 64 znaki, żeby zmieściły się długie frazy hasłowe. NIST mówi też, że weryfikatorzy powinni akceptować wszystkie drukowalne znaki ASCII i spację oraz akceptować Unicode, żeby nikomu nie blokować spacji ani znaków spoza alfabetu angielskiego.

Co kluczowe, ponad minimum długości NIST zabrania dokładania reguł składu. Ustawiasz minimalną długość, dopuszczasz hojne maksimum i na tym kończysz kwestię struktury. Siła bierze się z długości i nieprzewidywalności, nie z obowiązkowego symbolu.

Brak okresowych resetów bez powodu

Polityka nie powinna wygaszać haseł kalendarzowo. NIST: weryfikatorom „nie wolno wymagać od subskrybentów okresowej zmiany hasła", ale „muszą wymusić zmianę, jeśli istnieją dowody na to, że dany uwierzytelniacz został przejęty". To cała reguła. Zmieniasz hasło, gdy jest ku temu powód: potwierdzone albo podejrzewane przejęcie, ujawnienie w naruszeniu, współdzielone dane logowania wymagające rotacji albo odejście pracownika. Nie zmieniasz go dlatego, że minęły trzy miesiące.

To zmiana, którą liderzy uznają za najbardziej nieintuicyjną, bo rutynowe wygasanie sprawia wrażenie staranności. Warto to jasno zapisać w samej polityce, w jednym zdaniu z uzasadnieniem, żeby audytor albo świadomy bezpieczeństwa członek zarządu nie odczytał braku reguły 90 dni jako przeoczenia.

Sprawdzanie względem wyciekłych i popularnych haseł

Usunięcie reguł złożoności nie znaczy, że akceptujemy dowolne hasło. Kontrolą zastępczą jest sprawdzanie. NIST wymaga, żeby system, gdy użytkownik wybiera hasło, porównywał je z listą blokującą powszechnie używane, oczekiwane albo przejęte wartości, a jeśli hasło się na niej znajduje, żeby użytkownik musiał wybrać inne. To właśnie zatrzymuje kogoś, kto ustawia piętnastoznakowe hasło będące akurat Password12345678 albo frazą, która i tak siedzi w każdym korpusie wyciekłych haseł.

W praktyce oznacza to wpięcie sprawdzania pod kątem wyciekłych haseł w momencie tworzenia i zmiany hasła. Szeroko używaną darmową opcją jest usługa Pwned Passwords od Have I Been Pwned, która pozwala systemowi porównać hasło z miliardami wcześniej wyciekłych hashy bez wysyłania samego hasła, w modelu k-anonimowości, w którym przesyłany jest tylko krótki prefiks hasha. Istnieją komercyjne odpowiedniki integrowane w ten sam sposób. Microsoft Entra ID i wiele platform tożsamości ma wbudowaną funkcję blokowania zakazanych haseł, która robi podobną rzecz. Chodzi o to, żeby ciężar wiedzy o tym, które hasła są już spalone, niósł system, a nie użytkownik.

Pozwalaj na frazy hasłowe i menedżery haseł

Standardy aktywnie chcą, żeby ludzie używali długich fraz hasłowych i menedżerów haseł, a polityka powinna usunąć wszystkie przeszkody na tej drodze. NIST stwierdza, że weryfikatorzy „muszą dopuszczać korzystanie z menedżerów haseł i funkcji autouzupełniania" oraz powinni zezwalać na wklejanie do pola hasła, żeby menedżer mógł je wypełnić. Polityka albo formularz logowania blokujący wklejanie działa przeciwko standardowi i przeciwko użytkownikowi, bo pcha ludzi w stronę krótkich haseł, które da się wpisać z pamięci.

NCSC promuje podejście „trzy losowe słowa" dla haseł, które człowiek musi zapamiętać, na przykład hasła głównego do menedżera albo logowania do urządzenia: połączenie kilku niepowiązanych słów daje coś długiego, łatwego do zapamiętania i trudnego do złamania. Do wszystkiego innego menedżer haseł generuje i przechowuje długie losowe hasło dla każdej strony, więc człowiek nigdy nie musi go zapamiętywać ani używać ponownie. Ta kombinacja to współczesny domyślny model: niewielka liczba silnych zapamiętanych sekretów i menedżer trzymający unikalne, silne hasło do każdego konta.

Połącz to wszystko z MFA

Silne, unikalne, niewyciekłe hasło jest konieczne, ale niewystarczające. Chroni przed zgadywaniem i przed credential stuffing z użyciem ponownie wykorzystanych haseł. Nie chroni przed przekonującą stroną phishingową, która przechwytuje hasło w trakcie wpisywania, ani przed keyloggerem. To zadanie dla MFA: drugiego czynnika, którego napastnik mający tylko hasło i tak nie ma.

Te dwie kontrole obejmują różne tryby awarii, dlatego aktualne wytyczne traktują je razem. Dobre hasło nie wpuszcza zgadniętych albo złamanych danych logowania; MFA nie wpuszcza tych wyłudzonych phishingiem albo skradzionych. Wyższe poziomy pewności uwierzytelnienia NIST wymagają uwierzytelniania wieloskładnikowego właśnie z tego powodu. Polityka haseł, która nie wymusza też MFA na kontach, na których zależy, rozwiązuje tylko połowę problemu.

Krótka polityka, którą wdroży firma średniej wielkości

Oto polityka na tyle krótka, żeby faktycznie z niej korzystać, sformułowana tak, żeby nietechniczny czytelnik zrozumiał każdą linijkę. Dopasuj szczegóły do swojego dostawcy tożsamości, ale zachowaj strukturę.

1. Długość. Hasła muszą mieć co najmniej 15 znaków, gdy są używane samodzielnie. Tam, gdzie konto jest chronione MFA, akceptowalne jest minimum 8 znaków. System akceptuje hasła o długości co najmniej 64 znaków, w tym spacje i frazy hasłowe.

2. Brak obowiązkowej złożoności. Nie wymagamy konkretnego zestawienia wielkich liter, małych liter, cyfr ani symboli. Oczekujemy długości i nieprzewidywalności. Zachęcamy do używania frazy hasłowej z kilku losowych słów albo hasła wygenerowanego przez menedżer haseł.

3. Brak zaplanowanego wygasania. Hasła nie wygasają według harmonogramu. Zmianę wymuszamy tylko wtedy, gdy istnieją dowody albo uzasadnione podejrzenie przejęcia, w tym pojawienie się w znanym naruszeniu, rotacja współdzielonych danych logowania albo obawa o przejęcie konta.

4. Sprawdzanie przy tworzeniu. Każde nowe albo zmienione hasło jest sprawdzane względem listy popularnych, oczekiwanych i znanych wyciekłych haseł. Jeśli się na niej znajdzie, użytkownik jest proszony o wybranie innego. Robimy to za pomocą zautomatyzowanej usługi, więc samo hasło nigdy nie jest ujawniane w trakcie sprawdzania.

5. Menedżery haseł są wspierane i zalecane. Wklejanie do pól haseł jest dozwolone. Zapewniamy albo rekomendujemy menedżer haseł, żeby zespół trzymał unikalne hasło do każdego konta bez konieczności zapamiętywania ich.

6. MFA jest wymagane. Każde konto, które może sięgnąć po dane albo systemy firmy, korzysta z uwierzytelniania wieloskładnikowego, z czynnikami odpornymi na phishing (passkeye albo sprzętowe klucze bezpieczeństwa) na kontach administratorów i kontach uprzywilejowanych.

7. Ograniczanie liczby prób i blokada konta. Systemy logowania ograniczają liczbę powtarzanych nieudanych prób, żeby zgadywanie na dużą skalę nie było opłacalne, zgodnie z kontrolami weryfikatora.

To kompletna polityka. Jest krótsza niż większość tych, które zastępuje, a każda linijka ma oparcie w aktualnych wytycznych NIST albo NCSC.

Źródła

• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management (Rev. 4, 2024) · https://pages.nist.gov/800-63-4/sp800-63b.html (minimum 15 znaków dla pojedynczego czynnika, minimum 8 znaków w ramach MFA, maksimum co najmniej 64; „nie wolno narzucać innych reguł składu"; „nie wolno wymagać od subskrybentów okresowej zmiany hasła" oraz „trzeba wymusić zmianę, jeśli istnieją dowody" na przejęcie; sprawdzanie na liście blokującej popularne, oczekiwane i przejęte wartości; „trzeba dopuszczać korzystanie z menedżerów haseł", wklejanie dozwolone; ograniczanie liczby prób)
• UK NCSC, Password policy: updating your approach · https://www.ncsc.gov.uk/collection/passwords/updating-your-approach (reguły złożoności nie dają żadnej obrony i powinny zostać odrzucone; rutynowe wygasanie szkodzi bardziej, niż pomaga, i powinno zostać zastąpione zmianą po przejęciu; listy blokujące dla słabych haseł)
• UK NCSC, Three random words or #thinkrandom · https://www.ncsc.gov.uk/blog-post/three-random-words-or-thinkrandom-0 (podejście frazowe: łączenie kilku losowych słów dla długości i łatwości zapamiętania)
• Have I Been Pwned, Pwned Passwords · https://haveibeenpwned.com/Passwords (darmowe sprawdzanie wyciekłych haseł przez k-anonimowość, więc hasło nigdy nie jest wysyłane w całości; można używać przy tworzeniu i zmianie hasła)