Generator hasha hasła

Generator hasha hasła — bcrypt i Argon2id

Hasła w bazie danych należy przechowywać wyłącznie w postaci hasha, nigdy jawnie. bcrypt i Argon2id to dwa nowoczesne, celowo wolne algorytmy, które utrudniają atak słownikowy i brute-force.

bcrypt czy Argon2id?

Parametry kosztu

• bcrypt cost 10–12 — dobry kompromis między bezpieczeństwem a czasem logowania.
• Argon2id — reguluje się pamięcią, liczbą iteracji i wątkami; 64 MB i 4 iteracje to rozsądny start.
• Im wyższy koszt, tym wolniejsze łamanie — ale też wolniejsze logowanie.

Jak używać w kodzie?

W PHP użyj password_hash() do utworzenia hasha i password_verify() do sprawdzenia. Hash zawiera sól i parametry, więc do weryfikacji wystarczy sam hash i hasło.

Jak działa generator hasha hasła

Hashowanie hasła polega na przepuszczeniu go przez funkcję jednokierunkową, która z dowolnego wejścia tworzy wynik o stałej długości i której nie da się odwrócić. Do każdego wywołania generator dokłada świeżą, losową sól, więc ten sam tekst hasła daje za każdym razem inny hash. Sól oraz wszystkie parametry kosztu są zapisywane w samym ciągu hasha, dlatego do weryfikacji wystarczy hash z bazy i hasło podane przy logowaniu — nie trzeba przechowywać tych wartości osobno w konfiguracji aplikacji.

bcrypt to funkcja oparta na szyfrze Blowfish, a jej parametr cost jest wykładnikiem potęgi dwójki: cost 10 oznacza 2 do potęgi 10, czyli 1024 rund, a cost 12 to 2 do potęgi 12, czyli 4096 rund. Każde zwiększenie cost o 1 podwaja czas liczenia, więc różnica między 10 a 12 to dokładnie czterokrotność pracy. bcrypt ma jednak twardy limit wejścia: przetwarza tylko pierwsze 72 bajty hasła, a wszystko dłuższe jest obcinane.

Argon2id działa inaczej — zamiast samych rund mnoży pracę przez zajętość pamięci. Przy ustawieniu 64 MB i 4 iteracjach każde hashowanie wypełnia i przetwarza 64 MB cztery razy, co daje 256 MB pracy pamięciowej na jedno hasło. Taka konstrukcja utrudnia atak z użyciem kart graficznych, bo GPU ma dużo rdzeni, ale nie ma nieograniczonej pamięci na każdy równoległy wątek. Dodatkowy parametr liczby wątków pozwala wykorzystać wiele rdzeni procesora.

Przykład krok po kroku: hasło 80-bajtowe i cost 12

1. Przyjmij, że użytkownik ustawia hasło złożone z 80 znaków ASCII, czyli dokładnie 80 bajtów.
2. Generator wybiera algorytm bcrypt i parametr cost 12, co odpowiada 2 do potęgi 12, czyli 4096 rundom obliczeń.
3. bcrypt skraca wejście do 72 bajtów, więc do funkcji trafia tylko pierwsze 72 bajty — ostatnie 8 bajtów hasła nie ma żadnego wpływu na wynik.
4. Do tych 72 bajtów dokładana jest losowa sól, a całość przechodzi przez 4096 rund. Wynikiem jest gotowy hash, który zawiera już sól i parametr kosztu.
5. Gdy ten sam użytkownik loguje się ponownie, wpisuje pełne 80 znaków. System ponownie obcina je do 72 bajtów, odczytuje sól i cost z zapisanego hasha i liczy drugi hash. Oba ciągi są identyczne, więc weryfikacja przechodzi.
6. Ten sam test z cost 10 zamiast 12 zmniejsza liczbę rund z 4096 do 1024, czyli dokładnie czterokrotnie — hash wyjdzie inny, a logowanie będzie szybsze. Dla porównania Argon2id z pamięcią 64 MB i 4 iteracjami wykonuje 64 MB × 4 = 256 MB pracy pamięciowej na jedno hasło.

Parametry kosztu i limity — tabela referencyjna

Praktyczne wskazówki użycia

• Zacznij od cost 10 i podnoś go razem ze sprzętem — dopóki logowanie na serwerze produkcyjnym mieści się w akceptowalnym czasie, warto iść w stronę 12. Nie ustawiaj kosztu na sztywno na jednej maszynie i nie przenoś go bez testu na słabszy serwer.
• Pilnuj limitu 72 bajtów w bcrypt — jeśli dopuszczasz długie hasła albo znaki spoza ASCII, pamiętaj, że końcówka hasła nie wpływa na wynik. W takiej sytuacji bezpieczniej jest wybrać Argon2id.
• W Argon2id dostrajaj najpierw pamięć, potem iteracje — 64 MB i 4 iteracje to punkt wyjścia. Podniesienie pamięci mocniej zwiększa koszt łamania niż dodanie kolejnych iteracji.
• Nie przenoś hashy między środowiskami bez sprawdzenia parametrów — hash bcrypt z kosztem 12 będzie weryfikowany wolniej na maszynie, która była projektowana pod koszt 10.
• Traktuj wygenerowany hash jako dane wrażliwe — sam hash nie jest hasłem, ale nadal pozwala przeprowadzić atak offline, jeśli wycieknie razem z bazą.

Ograniczenia narzędzia i rzeczy, które zaburzają wynik

• Nie zmierzy czasu na Twoim serwerze — generowanie hasha zależy od procesora i obciążenia maszyny. Bez benchmarku po stronie aplikacji nie wiadomo, czy wybrany koszt jest dla Ciebie akceptowalny.
• Hash nie uratuje słabego hasła — wolny algorytm tylko spowalnia atak słownikowy. Krótkie i popularne hasło nadal padnie, choć zajmie to dłużej.
• Brak obsługi dodatkowego sekretu — narzędzie liczy hash wyłącznie z hasła i soli. Jeśli w produkcji używasz dodatkowego klucza po stronie serwera, wynik będzie inny i nie da się go bezpośrednio porównać.
• Nie sprawdza polityki haseł ani wycieków — nie odrzuci hasła z listy znanych wycieków ani nie ostrzeże o zbyt prostej konstrukcji. To zadanie osobnego mechanizmu w aplikacji.

Najczęstsze pytania