Dlaczego bcrypt jest ograniczony do 72 znaków?

Historyczne szczegóły implementacji podstawowego szyfru Blowfish. Dłuższe dane wejściowe są obcinane. Większość użytkowników tego nie zauważa; losowe hasło o długości 16 znaków jest znacznie poniżej limitu. W przypadku systemów wymagających nieograniczonej długości hasła Argon2 nie ma takich ograniczeń.

Czy powinienem solić i pieprzyć moje hasła?

Wymagana jest sól (a każda renomowana biblioteka robi to automatycznie). Pieprz jest opcjonalny, ale cenny w systemach o wysokim poziomie bezpieczeństwa. Kompromis: zarządzanie papryką jako długoterminową tajemnicą poza bazą danych zwiększa złożoność operacyjną. Większość aplikacji przechowuje sól i hash; największe przechowują sól + haszysz + haszysz pochodzący z pieprzu.

Czy Argon2 jest zawsze lepszy niż bcrypt?

Dla nowych systemów tak. Argon2 ma ograniczoną pamięć (odporną na GPU/ASIC), nie ma limitu 72 znaków i nie bez powodu wygrał konkurs hashowania haseł. bcrypt jest nadal akceptowalny, gdy Argon2 nie jest dostępny lub ograniczenia organizacyjne preferują starszy standard. W przypadku starszych systemów korzystających z bcrypt o koszcie ≥ 10, pilność migracji jest niewielka.

Ile czasu powinno zająć hashowanie hasła?

OWASP sugeruje około 100-500 ms na sprzęcie serwera. Szybszy oznacza słabszy wobec atakujących; wolniejsze zaczyna wpływać na legalność logowania. Właściwa liczba zależy od ruchu — usługi o dużym wolumenie wybierają niższy koszt; usługi o wysokim poziomie bezpieczeństwa i niskim współczynniku logowania mogą wybierać wyższe.

Czy mogę przechowywać hasła w postaci zaszyfrowanej zamiast zaszyfrowanej?

Nie. Szyfrowanie jest odwracalne, co oznacza, że klucz szyfrujący musi znajdować się w miejscu, do którego aplikacja może uzyskać dostęp. Jeśli baza danych zostanie naruszona, klucz często również zostanie naruszony, a Ty skutecznie przechowujesz zwykły tekst. Chodzi o nieodwracalność hashowania — nawet Twoja własna aplikacja nie jest w stanie odzyskać hasła, co jest właściwością bezpieczeństwa.

Wyjaśnienie mieszania haseł: dlaczego bcrypt, scrypt i Argon2 mają znaczenie

Przechowywanie haseł użytkowników to jedna z najgorszych możliwych rzeczy, jakie można zrobić w postaci zwykłego tekstu, i jeden z najczęstszych błędów związanych z bezpieczeństwem. Poprawka istnieje od dziesięcioleci — mieszanie haseł za pomocą powolnych algorytmów obciążających pamięć — ale różnica między dobrymi i złymi implementacjami jest ogromna, a większość naruszeń danych ujawnia złe wybory.

Poniżej znajduje się pełna treść artykułu w języku angielskim.

Haszowanie hasła to praktyka polegająca na przechowywaniu jednokierunkowej transformacji hasła użytkownika zamiast samego hasła. Kiedy użytkownik się loguje, ta sama transformacja jest stosowana do jego danych wejściowych i porównywana z przechowywaną wartością. W przypadku naruszenia przechowywanej bazy danych osoba atakująca dysponuje skrótami, a nie hasłami, a odzyskanie oryginałów powinno być niewykonalne obliczeniowo.

Taka jest teoria. Praktyka waha się od „działa zgodnie z reklamą” do „równie dobrze może być zwykłym tekstem”, w zależności od wybranego algorytmu i parametrów.

Czego potrzebuje dobry skrót hasła

Jednokierunkowa. Znajomość skrótu nie powinna ujawnić niczego przydatnego na temat hasło.
Salted. Każdy użytkownik ma unikalną losową sól wmieszaną w hash. Zapobiega wstępnie obliczonym tabelom Rainbow i zapewnia, że identyczne hasła generują różne skróty.
Slow. Pojedyncze obliczenie skrótu powinno zająć znaczący ułamek sekundy na sprzęcie atakującego. Brutalna siła rzędu miliardów na sekundę pokonuje szybkie skróty.
Trudna pamięć. Każdy skrót powinien wymagać znacznej ilości pamięci RAM, pokonując równoległość GPU i ASIC, która rozwija się w przypadku małej pamięci przypadającej na instancję.
Parametry przyszłościowe. Czynniki kosztowe powinny być dostosowywane w górę w miarę sprzęt staje się szybszy.

Złe wybory

Algorytmy, których nigdy nie wolno używać do przechowywania haseł:

MD5. Łamane kryptograficznie od 2004 r. Możliwość brutalnego wymuszenia przy dziesiątkach miliardów skrótów na sekundę dla konsumenta hardware.
SHA-1, SHA-256. Szybkie skróty kryptograficzne przeznaczone do sprawdzania integralności, a nie do przechowywania haseł. Możliwość brutalnego wymuszenia na procesorach graficznych z szybkością miliardów na sekundę.
Zaszyfrowane hasła. Jeśli możesz je odszyfrować z powrotem do postaci zwykłego tekstu, atakujący, który ukradnie klucz, też to zrobi. Haszowanie jest odpowiedzią; szyfrowanie nie jest.
Zwykły tekst. Nadal ma to miejsce w 2026 r. Każdemu naruszeniu hasła w postaci zwykłego tekstu można zapobiec dzięki inżynierii.

Właściwe wybory

Zalecane są trzy nowoczesne algorytmy:

bcrypt (1999). Regulowany współczynnik kosztu (rundy obliczeń). Ograniczone do haseł 72-bajtowych. Nie wymaga dużej ilości pamięci, więc procesory graficzne mogą ją skutecznie atakować – ale rozsądny współczynnik kosztów nadal sprawia, że ataki są drogie. Szerokie wdrożenie, proste w użyciu.
scrypt (2009). Trudno zapamiętać. Konfigurowalny koszt pamięci, równoległość i koszt procesora. Bardziej złożone niż bcrypt; czasami błędnie skonfigurowane.
Argon2 (Zwycięzca konkursu hashowania haseł 2015). Trzy warianty: Argon2d (zależny od danych, odporny na ataki GPU, ale podatny na kanały boczne), Argon2i (niezależny od danych, odporny na kanały boczne), Argon2id (hybrydowy — zalecane ustawienie domyślne). Nowoczesny, dobrze sprawdzony, właściwy wybór dla nowych systemów.

OWASP obecnie zaleca Argon2id z co najmniej 19 MB pamięci, liczbą iteracji 2 i równoległością 1. W przypadku systemów, w których Argon2 nie jest dostępny, akceptowalne rozwiązania awaryjne to bcrypt o koszcie ≥ 10 lub scrypt z odpowiednimi parametrami.

Co oznacza „wolny” w praktyka

Współczynnik kosztu równy 10 w bcrypt oznacza około 100 ms na skrót na nowoczesnym sprzęcie. Dla zalogowanego użytkownika jest to niezauważalne. Dla atakującego próbującego brutalnie wymusić 100 milionów haseł z bazy danych, która wyciekła, jest to 100 milionów × 100 ms = 116 dni czasu procesora graficznego na przejście przez rozsądną listę słów. W połączeniu z unikalną solą na użytkownika duże tablice Rainbow są bezużyteczne.

W przypadku szybkiego skrótu, takiego jak niesolony SHA-256, ta sama operacja zajmuje kilka minut na tym samym sprzęcie.

Obsługa soli

Salta jest na użytkownika, generowana przez CSPRNG u użytkownika utworzenie
16 bajtów wystarczy (128 bitów losowości)
Salt jest przechowywany obok skrótu, a nie tajemnicy — jego zadaniem jest być unikalnym, a nie ukrytym
Większość nowoczesnych bibliotek mieszających (bcrypt, wyjścia Argon2 w formacie ciągu PHC) łączy algorytm, parametry, sól i skrót w jeden string

Pepper: opcjonalny extra

A pepper to tajna wartość dla całej witryny dodana do danych wejściowych skrótu, przechowywana oddzielnie od bazy danych (w module HSM, magazynie kluczy lub konfiguracji aplikacji). Jeśli baza danych zostanie zrzucona, ale pieprz nie, skróty będą nie do odzyskania nawet przy użyciu soli użytkownika — ponieważ atakujący nie ma pieprzu. Pepper to przydatny dodatek do paska i szelek w systemach o wysokiej wartości.

Bezpieczne aktualizowanie skrótów

Kiedy zmieniasz parametry lub migrujesz algorytmy, nie możesz ponownie hashować bez oryginalnego hasła. Podejście standardowe:

Każdy rekord użytkownika przechowuje swój aktualny algorytm mieszający, parametry, sól i skrót.
Podczas logowania sprawdź przechowywany skrót z jego oryginalnymi parametrami.
Jeśli weryfikacja się powiedzie, a parametry będą nieaktualne, wykonaj ponownie hash z bieżącymi parametrami i zaktualizuj rekord.

W ciągu kilku miesięcy aktywnych użytkowników, baza danych przechodzi na nowe parametry bez konieczności resetowania haseł.

Co to oznacza dla użytkowników

Dla użytkowników końcowych praktyczny efekt: nawet w przypadku naruszenia bazy danych silne, unikalne hasło (zarządzane przez menedżer haseł) oraz dobre haszowanie na serwerze oznaczają, że hasło pozostaje skutecznie tajne. Słabe hasła są łamane nawet w dobrze zaszyfrowanych bazach danych; użytkownik jest zmienną, której programista nie może kontrolować.

Często zadawane pytania

Dlaczego bcrypt jest ograniczony do 72 znaków?: Historyczne szczegóły implementacji podstawowego szyfru Blowfish. Dłuższe dane wejściowe są obcinane. Większość użytkowników tego nie zauważa; losowe hasło o długości 16 znaków jest znacznie poniżej limitu. W przypadku systemów wymagających nieograniczonej długości hasła Argon2 nie ma takich ograniczeń.
Czy powinienem solić i pieprzyć moje hasła?: Wymagana jest sól (a każda renomowana biblioteka robi to automatycznie). Pieprz jest opcjonalny, ale cenny w systemach o wysokim poziomie bezpieczeństwa. Kompromis: zarządzanie papryką jako długoterminową tajemnicą poza bazą danych zwiększa złożoność operacyjną. Większość aplikacji przechowuje sól i hash; największe przechowują sól + haszysz + haszysz pochodzący z pieprzu.
Czy Argon2 jest zawsze lepszy niż bcrypt?: Dla nowych systemów tak. Argon2 ma ograniczoną pamięć (odporną na GPU/ASIC), nie ma limitu 72 znaków i nie bez powodu wygrał konkurs hashowania haseł. bcrypt jest nadal akceptowalny, gdy Argon2 nie jest dostępny lub ograniczenia organizacyjne preferują starszy standard. W przypadku starszych systemów korzystających z bcrypt o koszcie ≥ 10, pilność migracji jest niewielka.
Ile czasu powinno zająć hashowanie hasła?: OWASP sugeruje około 100-500 ms na sprzęcie serwera. Szybszy oznacza słabszy wobec atakujących; wolniejsze zaczyna wpływać na legalność logowania. Właściwa liczba zależy od ruchu — usługi o dużym wolumenie wybierają niższy koszt; usługi o wysokim poziomie bezpieczeństwa i niskim współczynniku logowania mogą wybierać wyższe.
Czy mogę przechowywać hasła w postaci zaszyfrowanej zamiast zaszyfrowanej?: Nie. Szyfrowanie jest odwracalne, co oznacza, że klucz szyfrujący musi znajdować się w miejscu, do którego aplikacja może uzyskać dostęp. Jeśli baza danych zostanie naruszona, klucz często również zostanie naruszony, a Ty skutecznie przechowujesz zwykły tekst. Chodzi o nieodwracalność hashowania — nawet Twoja własna aplikacja nie jest w stanie odzyskać hasła, co jest właściwością bezpieczeństwa.