losowaliczba.pl

Dlaczego NIST odchodzi od wymogu znaku specjalnego

Co mówi NIST

Amerykański instytut norm NIST opisuje logowanie w serii wytycznych SP 800-63. Część o hasłach, SP 800-63B, w czwartej wersji z 2025 roku stawia wymagania serwisom, które hasła sprawdzają. Są pisane dla amerykańskiej administracji, ale opierają się na badaniach haseł z prawdziwych wycieków i dobrze pasują do każdego serwisu.

Najważniejsze wymagania (§3.1.1 i §3.2.2):

  • Hasło, które jest jedynym zabezpieczeniem konta, ma mieć co najmniej 15 znaków. Jeśli hasło jest tylko jednym z czynników uwierzytelniania wieloskładnikowego (MFA), serwis może dopuścić minimum 8. Dwa kroki logowania to nie zawsze dwa czynniki: hasło i pytanie pomocnicze to wciąż dwie rzeczy, które się wie.
  • Serwis powinien obsługiwać hasła o długości co najmniej 64 znaków, ze spacjami i polskimi literami (Unicode).
  • Zakaz reguł składu: serwis nie może wymagać mieszanki wielkich liter, cyfr i znaków specjalnych.
  • Zakaz okresowej zmiany hasła. Zmianę trzeba wymusić wtedy, gdy są dowody, że hasło zostało skompromitowane, np. poznała je osoba nieuprawniona.
  • Nowe hasło trzeba porównać z listą haseł popularnych, przewidywalnych i znanych z wycieków, i odrzucić, jeśli na niej jest.
  • Serwis nie może udostępniać podpowiedzi do hasła osobom niezalogowanym ani prosić przy wyborze hasła o odpowiedzi na pytania o fakty z życia, w rodzaju „imię pierwszego zwierzaka”.
  • Serwis sprawdza całe hasło: nie obcina go i nie prosi o wybrane znaki.
  • Serwis musi pozwalać na menedżery haseł i autouzupełnianie, a powinien też pozwalać na wklejanie.
  • Serwis ogranicza liczbę nieudanych prób: najwyżej 100 z rzędu, potem logowanie tym hasłem zostaje zablokowane. Może przyjąć niższy limit.

Dwa zakazy brzmią jak herezja, bo przez lata uczono odwrotnie. NIST odradzał reguły składu i okresową zmianę już w poprzedniej wersji wytycznych z 2017 roku (SP 800-63B, „SHOULD NOT”), a w czwartej wersji ich zakazuje („SHALL NOT”). Za oboma stoją pomiary.

Reguły składu: więcej wymagań, przewidywalne hasła

Reguła „wielka litera, cyfra i znak specjalny” ma sens dla generatora: większy zestaw znaków to więcej możliwości na każdej pozycji. Hasła wybierają jednak ludzie, a ludzie odpowiadają na reguły przewidywalnie. Słowo dostaje wielką literę na początku, cyfry i wykrzyknik lądują na końcu. NIST w dodatku A do wytycznych podaje przykład: z „password” robi się „Password1!”. Spełnia reguły, ale atakujący też zna ten nawyk.

Zespół z Carnegie Mellon zmierzył to na tysiącach haseł utworzonych przez uczestników badań według różnych polityk. W badaniu z 2011 roku (ok. 5 000 osób) hasła z jedną regułą „co najmniej 16 znaków” miały w szacunku autorów (według ich metody, do porównań między politykami) 44,7 bitu entropii, a hasła z regułą „co najmniej 8 znaków, wielka i mała litera, cyfra, znak specjalny, bez słów ze słownika” – 34,3 bitu. Według ówczesnych tabel NIST obie polityki miały być równie mocne. Długie hasła było przy tym łatwiej utworzyć i rzadziej je zapisywano.

W badaniu z 2012 roku ten sam zespół łamał 12 000 haseł z siedmiu polityk. Przy miliardzie prób hasła z regułami składu trzymały się lepiej (złamano 1,4% wobec 9,5% długich). Przy większej liczbie prób kolejność się odwróciła: na końcu symulacji, przerwanej po 50 bilionach prób, złamano 26,4% haseł z regułami i 14,6% długich, a z hasłami „co najmniej 8 znaków, bez innych reguł” – 63%. Reguły składu nie są więc bezwartościowe, ale ich skutek zależy od całej polityki i od tego, jak długo atakujący może zgadywać.

Sprawdź, ile bitów dają rodzaje znaków, a ile długość. Dla haseł losowanych równomiernie każdy bit entropii podwaja liczbę możliwości, a w przybliżeniu także średnią liczbę prób. Szacunki entropii haseł wymyślanych przez ludzi nie przekładają się tak prosto na odporność.

Reguły kontra długość

Długość losowego hasła8 znaków

Rodzaje znaków

Atak po wycieku bazy haseł

Czas to średnia przy losowaniu równomiernym: połowa przestrzeni podzielona przez szybkość. Obie szybkości to założenia przykładu (wolny wariant to 1 000 000 razy mniej prób na sekundę). Prawdziwa zależy od funkcji skrótu, jej parametrów i sprzętu.

  • Kasia12! – słowo, 2 cyfry i znak według reguł29,9 bitu · poniżej sekundy

  • Twoje ustawienia: 8 losowych znaków z 9452,4 bitu · 4 dni

  • 8 losowych znaków ze wszystkich 9452,4 bitu · 4 dni

  • 5 losowych słów z listy EFF (7 776)64,6 bitu · 45 lat

  • 15 losowych małych liter (minimum NIST)70,5 bitu · 3 tys. lat

  • Domyślne hasło naszego generatora (16 znaków, każdy rodzaj co najmniej raz)95,2 bitu · 71 mld lat

Wybrane rodzaje znaków dają 14,8 bitu więcej niż 8 małych liter. Co najmniej tyle samo da wydłużenie hasła z samych małych liter o 4 znaki: 12 losowych małych liter to 56,4 bitu.

Wiersze „losowych znaków” liczymy jako losowanie z całego zestawu, bez wymogu, by każdy rodzaj wystąpił. Wymóg odrobinę zmniejsza liczbę możliwości, dlatego wiersz naszego generatora liczy jego własna funkcja.

Wiersz „Kasia12!” to model, nie pomiar: słownik miliona słów i imion, dwie cyfry, jeden z dziesięciu znaków z rzędu cyfr. Reguły spełnione, a cała ta przestrzeń to miliard haseł: przy szybkim skrócie atakujący sprawdzi ją w ułamku sekundy, przy wolnym trafi średnio po ok. 14 godzinach.

Wniosek dla losowych haseł: każda dodatkowa mała litera to 4,7 bitu. Wszystkie cztery rodzaje znaków dodane do 8-znakowego hasła są warte mniej więcej trzy litery więcej. Długość łatwiej zapamiętać, a reguły wymuszone na człowieku mogą prowadzić do haseł zbudowanych według kilku przewidywalnych schematów.

Okresowa zmiana hasła

Zmiana hasła co 90 dni miała odciąć atakującego, który hasło już zna. Działa to tylko wtedy, gdy nowe hasło nie wynika ze starego. Badacze z Uniwersytetu Karoliny Północnej sprawdzili to w 2010 roku na ponad 7 700 kontach swojej uczelni. Hasło trzeba tam było zmieniać co trzy miesiące i musiało mieć co najmniej 8 znaków, literę, cyfrę i znak specjalny.

Znając stare hasło, badacze odgadywali nowe w 41% kont, średnio w mniej niż 3 sekundy obliczeń. W 17% kont wystarczało średnio mniej niż 5 prób, czyli daleko poniżej pułapu nieudanych logowań z wytycznych NIST. Sprawdzane przeróbki to m.in. podbicie liczby (tar!heel1 → tar!heel2), dopisanie cyfry, zamiana symbolu, ten sam klawisz z Shiftem, zmiana wielkości liter i zamiany w rodzaju a → @.

Wpisz stare hasło i jego „następcę”. Demonstracja to nasz uproszczony model, nie algorytm z badania: sprawdza wybrane przeróbki i ich pary w ustalonej przez nas kolejności, do 5 000 różnych prób. Dodaliśmy też zmianę pory roku i miesiąca, której badanie nie obejmowało.

Przewidywalny następca

Wszystko liczy się w przeglądarce, nic nie jest wysyłane. Mimo to nie wpisuj tu prawdziwych haseł.

Trafione w 5. próbie

To przed pułapem 100 kolejnych nieudanych prób, który NIST wyznacza jako górną granicę. Czy atak przez stronę logowania się uda, zależy jeszcze od limitów serwisu i od drugiego składnika logowania.

Pierwsze próby atakującego (757 wszystkich)

  1. 1.Lato2027!
  2. 2.Lato2028!
  3. 3.Lato2029!
  4. 4.Lato2025!
  5. 5.Jesien2026!
  6. 6.Jesień2026!
  7. 7.Zima2026!
  8. 8.Wiosna2026!
  9. 9.Lato2026!1
  10. 10.Lato2026!!
  11. 11.Lato2026@
  12. 12.Lato2026#
  13. 13.Lato2026$
  14. 14.Lato2026%
  15. 15.Lato2026&
  16. 16.Lato2026*
  17. 17.Lato2026?
  18. 18.Lato2026.
  19. 19.Lato@026!
  20. 20.Lato2)26!
  21. 21.Lato20@6!
  22. 22.Lato202^!
  23. 23.Lato20261
  24. 24.Lato22026!

Kolejność to nasz przykładowy model, nie algorytm z badania: najpierw zmiany liczb, potem pora roku lub miesiąc, dopisany znak, inny symbol, ten sam klawisz z Shiftem, podwojony znak, wielkość liter, zamiany typu a → @, usunięcia. Potem pary takich zmian, do 5000 różnych prób.

Dlatego NIST zakazuje okresowej zmiany. Hasło zmienia się wtedy, gdy są dowody, że ktoś je poznał: wyciek, phishing, podejrzane logowanie.

Inne wymogi, które szkodzą

  • Limit długości („maksymalnie 20 znaków”) i zakaz spacji blokują frazy z kilku słów, czyli najłatwiejszy sposób na długie hasło do zapamiętania. NIST zaleca przyjmować co najmniej 64 znaki i spacje.
  • Blokada wklejania zniechęca do menedżera haseł i skłania do wpisywania krótkich haseł z pamięci. NIST wymaga obsługi menedżerów haseł i zaleca pozwolić na wklejanie.
  • Pytania pomocnicze zamieniają hasło na fakt z życia, który da się znaleźć w mediach społecznościowych. NIST zabrania o nie prosić przy wyborze hasła, a podpowiedzi do hasła nie mogą być dostępne dla osób niezalogowanych.
  • Wybrane znaki hasła („podaj 2., 5. i 9. znak”) to praktyka niektórych banków. NIST wymaga, by serwis prosił o całe hasło i sprawdzał je w całości.

Co naprawdę chroni konto

  • Długość i losowość. Co najmniej 15 znaków albo fraza z kilku losowych słów. Losowych, czyli wybranych przez generator haseł, nie przez człowieka.
  • Inne hasło do każdego serwisu. Wyciek z jednego sklepu nie otwiera wtedy poczty. Zapamiętanie tego umożliwia menedżer haseł.
  • Sprawdzenie w bazie wycieków. Hasło, które już wyciekło, jest na liście atakującego, choćby wyglądało na mocne.
  • Drugi składnik logowania. Kod z aplikacji albo klucz sprzętowy chroni konto nawet wtedy, gdy hasło wpadnie w złe ręce.

Jak działa nasz generator i jak to sprawdzić

Generator haseł na tej stronie ma być wiarygodny nie dlatego, że tak piszemy, tylko dlatego, że każdy element da się sprawdzić:

  • Hasło powstaje w przeglądarce i nigdzie nie jest wysyłane. Generator łączy się tylko z siecią drand (pobiera publiczną rundę losowości) i z bazą wycieków Have I Been Pwned, do której trafia 5 pierwszych znaków skrótu SHA-1 hasła. Baza odsyła wszystkie skróty z tym początkiem, a porównanie odbywa się u Ciebie. Sprawdzisz to w narzędziach deweloperskich przeglądarki, w zakładce Sieć.
  • Źródłem jest generator kryptograficzny przeglądarki (crypto.getRandomValues): 32 bajty, czyli 256 bitów. Czy jego implementacja spełnia wymagania NIST, zależy od przeglądarki i systemu operacyjnego, ich wersji oraz konfiguracji. Z poziomu strony nie da się tego potwierdzić. O tym, skąd komputer bierze losowość, piszemy w artykule o entropii i generatorach.
  • Test zdrowia przed użyciem. Na wzór testów ciągłych z normy NIST SP 800-90B (test liczby powtórzeń i test proporcji) generator sprawdza próbkę bajtów i to, czy kolejne losowania się różnią. Zepsuty generator, który zwraca zera albo stałą wartość, nie przejdzie i hasło nie powstanie. Testy nie certyfikują źródła, tylko łapią awarię.
  • Mieszanie bez przechwalania się. Do bajtów z przeglądarki dochodzi losowość rundy drand i, jeśli je włączysz, dane z ruchów myszy, a całość przechodzi przez funkcję HKDF-SHA256 (RFC 5869). Do entropii liczymy tylko 256 bitów z przeglądarki: runda drand jest publiczna, a ruchów myszy nie da się rzetelnie zmierzyć.
  • Każdy znak równie prawdopodobny. Znaki są losowane metodą odrzucania, bez stronniczości modulo. Jeśli w haśle brakuje wymaganego rodzaju znaków, całe hasło jest losowane od nowa, zamiast dopisywać brakujący znak na siłę, więc wszystkie poprawne hasła są równie prawdopodobne. Raz użyty bajt losowości nie jest używany ponownie.
  • Uczciwa entropia. Pokazana entropia jest liczona dokładnie dla wybranych ustawień i nigdy nie przekracza 256 bitów ziarna: 128-znakowe hasło nie jest mocniejsze niż źródło, z którego powstało.
  • Lista kontrolna NIST. Przy każdym haśle generator sprawdza wybrane właściwości: długość wobec progów 15 i 8 znaków, czy hasło mieści się w zalecanym zakresie obsługiwanych długości, czy występuje w bazie wycieków Have I Been Pwned, oraz siłę ziarna. Zaznacza też, czego strona nie sprawdzi: czy generator przeglądarki spełnia wymagania NIST. Nie ocenia pełnej polityki docelowego serwisu ani jego listy zakazanych haseł. To nasza ocena, a nie certyfikat.
  • Pokwitowanie bez hasła. Generator może wydać pokwitowanie w formacie JSON: numer rundy drand, użyte źródła i skrót ustawień. Pokwitowanie nie zawiera hasła i nie pozwala go odtworzyć, a sprawdzisz je na stronie weryfikacji losowania.

Źródła: NIST SP 800-63B-4, §3.1.1, §3.2.2 i dodatek A, NIST SP 800-63B (2017), §5.1.1.2, NIST SP 800-90B, §4.4, S. Komanduri i in., „Of Passwords and People” (CHI 2011), P. G. Kelley i in., „Guess Again (and Again and Again)” (IEEE S&P 2012), Y. Zhang, F. Monrose, M. K. Reiter, „The Security of Modern Password Expiration” (ACM CCS 2010), RFC 5869 (HKDF).

Powiązane narzędzia