bcrypt vs Argon2: wybór ustawień hashowania haseł

Jaki problem rozwiązuje hashowanie haseł

Hashowanie haseł pozwala backendowi przechowywać informację o haśle bez zapisywania samego hasła. Gdy ktoś się rejestruje, serwer przepuszcza hasło przez funkcję jednokierunkową i zapisuje wynik (hash). Przy logowaniu hasło wpisane przez użytkownika jest zhashowane i porównane z tym, co jest w bazie.

Hash to nie szyfrowanie. Nie da się go odszyfrować. Ta jednokierunkowość właśnie sprawia, że hashowanie jest stosowane do haseł.

Dlaczego więc nie użyć zwykłego, szybkiego skrótu jak SHA-256? Bo „szybkie” to jest to, czego chcą atakujący. Gdy baza zostanie skradziona, atakujący nie zgadują haseł przez próby logowania pojedynczo — zgadują offline, przesyłając jak najwięcej prób zgodnie z możliwościami sprzętu. Z GPU szybkie hashe można testować masowo. Nawet przy unikalnych solach szybki hash wciąż jest tani do bruteforce’u.

Rzeczywisty scenariusz porażki: mała aplikacja traci tabelę użytkowników w wycieku. Atakujący zdobywa e-maile i hashe. Jeśli hashe powstały przy użyciu szybkiej funkcji, popularne hasła i ich drobne warianty zostaną złamane szybko. Potem atakujący próbuje te same hasła na innych serwisach (credential stuffing) lub wykorzystuje je do uzyskania wyższych uprawnień w twojej aplikacji.

Dobry hash sprawia, że zgadywanie jest kosztowne. Celem nie jest „niezłamalność”, a raczej „zbyt wolne i kosztowne, żeby się opłacało”.

Konfiguracja hashowania haseł powinna być:

• jednokierunkowa (weryfikacja, nie odwracanie)
• wolna dla każdej próby
• kosztowna przy sprzęcie równoległym (szczególnie GPU)
• wystarczająco szybka, żeby logowania wydawały się normalne
• regulowalna, żeby dało się podnosić koszt z czasem

bcrypt i Argon2 w pigułce

Porównując bcrypt vs Argon2, wybierasz sposób spowolnienia zgadywania haseł po wycieku bazy.

bcrypt to starsza, szeroko wspierana opcja. Został zaprojektowany, by był kosztowny dla CPU i ma jedno główne pokrętło: współczynnik kosztu. Jest też „nudny” w dobrym sensie: łatwo go znaleźć w bibliotekach, łatwo wdrożyć i jest przewidywalny.

Argon2 jest nowszy i zaprojektowany jako pamięciochłonny. Może wymusić, by każda próba hashowania używała znaczącej ilości RAM, a nie tylko CPU. To ważne, bo atakujący często wygrywają, uruchamiając ogromną liczbę prób równolegle na GPU lub wyspecjalizowanym sprzęcie. Pamięć jest trudniejsza i droższa do skalowania przy takim poziomie równoległości.

Argon2 ma trzy warianty:

• Argon2i: kładzie nacisk na odporność na niektóre ataki przez kanały boczne
• Argon2d: kładzie nacisk na odporność na GPU, przy pewnych kompromisach względem kanałów bocznych
• Argon2id: praktyczne połączenie obu, najczęstszy wybór do hashów haseł

Jeśli twój stack wspiera Argon2id i możesz bezpiecznie skalibrować pamięć, zwykle jest to najlepszy nowoczesny domyślny wybór. Jeśli potrzebujesz maksymalnej kompatybilności ze starymi systemami, bcrypt wciąż jest solidnym wyborem przy odpowiednio wysokim współczynniku kosztu.

Właściwości bezpieczeństwa, które mają znaczenie

Pytanie podstawowe brzmi: jeśli atakujący zdobędzie bazę haseł, jak drogie jest zgadywanie haseł na dużą skalę?

W przypadku bcrypt kontrolujesz koszt (czynnik pracy). Wyższy koszt oznacza, że każda próba trwa dłużej. To spowalnia atakujących, ale też twoje własne weryfikacje przy logowaniu, więc dobierasz go tak, żeby był bolesny dla atakujących, lecz akceptowalny dla użytkowników.

W Argon2id możesz dodać pamięciochłonność oprócz kosztu czasowego. Każda próba wymaga czasu CPU i dostępu do RAM w określonym wzorcu. GPU są bardzo szybkie w zadaniach obliczeniowych, ale tracą przewagę, gdy każda równoległa próba potrzebuje znacznej ilości pamięci.

Sole są niezbędne. Unikalna, losowa sól dla każdego hasła:

• uniemożliwia ponowne użycie wstępnie obliczonych tablic na całej bazie
• zapewnia, że identyczne hasła nie dają identycznych hashy dla różnych użytkowników

Sole same w sobie nie czynią słabych haseł silnymi. Chronią głównie po wycieku bazy, zmuszając atakujących do pracy per użytkownik.

Mocne i ograniczenia bcrypt, o których warto wiedzieć

bcrypt jest nadal szeroko używany, głównie dlatego, że łatwo go wdrożyć wszędzie. Sprawdza się, gdy potrzebujesz dużej interoperacyjności, gdy twój stack ma ograniczone opcje kryptograficzne lub gdy chcesz prostego pokrętła do strojenia.

Największy „zastrzyk” to limit 72 bajtów. bcrypt używa tylko pierwszych 72 bajtów hasła i ignoruje resztę. To może zaskoczyć osoby korzystające z długich fraz lub menedżerów haseł.

Jeśli wybierzesz bcrypt, jasno określ sposób obsługi długości hasła. Albo egzekwuj maksymalną długość (w bajtach, nie znakach), albo konsekwentnie traktuj długie wejścia we wszystkich usługach. Chodzi o uniknięcie cichego obcinania, które zmienia to, co użytkownik uważa za swoje hasło.

bcrypt jest też mniej odporny na nowoczesny, równoległy sprzęt do łamania niż opcje pamięciochłonne. Jego obrona nadal działa, ale zależy mocno od ustawienia współczynnika kosztu, które uczyni każdą próbę kosztowną.

Jeżeli budujesz nowy system lub masz konta o wysokiej wartości (płatne plany, role admina), powszechną i niskoryzykowną ścieżką jest migracja nowych hashy do Argon2id, przy jednoczesnym akceptowaniu istniejących bcrypt hashy do momentu, gdy użytkownik się zaloguje.

Zalety Argon2 i kompromisy

Argon2 został stworzony z myślą o hashach haseł. Argon2id to wariant, który zespoły zwykle wybierają, bo równoważy odporność na GPU i rozsądną ochronę przed atakami przez kanały boczne.

Argon2id daje trzy parametry:

• Pamięć (m): ile RAM używa każdy hash podczas działania
• Czas/iteracje (t): ile przebiegów po tej pamięci wykonuje
• Równoległość (p): ile „linii” wykorzystuje (pomaga na wielordzeniowych CPU)

Pamięć to główna przewaga. Jeśli każda próba wymaga znaczącej ilości RAM, atakujący nie mogą uruchamiać tylu prób równolegle bez ponoszenia dużych kosztów na pamięć i jej przepustowość.

Minus to aspekt operacyjny: więcej pamięci na hash oznacza mniej równoczesnych logowań zanim serwery poczują presję. Jeśli ustawisz pamięć za wysoko, skoki logowań mogą powodować kolejki, timeouty, a nawet błędy out-of-memory. Trzeba też myśleć o nadużyciach: wiele równoległych prób logowania może stać się problemem zasobowym, jeśli nie ograniczysz pracy.

Aby Argon2id był bezpieczny i użyteczny, stroj go jak funkcję wydajności:

• wykonaj benchmarki na sprzęcie zbliżonym do produkcyjnego
• ogranicz równoległą pracę hashowania (limity workerów, kolejki)
• narzucaj limity szybkości prób logowania i blokuj powtarzające się niepowodzenia
• trzymaj ustawienia spójne we wszystkich usługach, by jedno słabe API nie stało się celem

Koszty wydajności w realnych backendach webowych

W hashowaniu haseł „szybsze jest lepsze” to zwykle zły cel. Chcesz, żeby każda próba była kosztowna dla atakujących, a jednocześnie logowania musiały pozostać responsywne.

Praktyczny sposób ustawienia to budżet czasowy na weryfikację na twoim rzeczywistym sprzęcie produkcyjnym. Wiele zespołów celuje w coś w rodzaju 100–300 ms na sprawdzenie, ale właściwa wartość zależy od ruchu i serwerów. Różnica między bcrypt a Argon2 polega na tym, za co płacisz: bcrypt to głównie czas CPU, Argon2 może też rezerwować pamięć.

Wybierz docelowy czas, potem mierz

Wybierz docelowy czas hashu i przetestuj w warunkach przypominających produkcję. Mierz zarówno hashowanie przy rejestracji/zmianie hasła, jak i weryfikację przy logowaniu — traktuj logowanie jako gorącą ścieżkę.

Lekki plan pomiarowy:

• testuj 1, 10 i 50 równoczesnych weryfikacji i zapisz opóźnienia p50 i p95
• powtarzaj uruchomienia, by zmniejszyć szum od cache i boostu CPU
• mierz osobno wywołania do bazy, żeby wiedzieć, ile naprawdę kosztuje hash
• testuj w tym samym kontenerze i z tymi samymi limitami CPU, które wdrażasz

Skoki mają większe znaczenie niż średnie

Większość systemów zawodzi podczas szczytów. Jeśli marketingowy e-mail sprowadzi falę użytkowników do logowania, twoje ustawienia hashowania zdecydują, czy system pozostanie responsywny.

Jeśli jedna weryfikacja trwa 250 ms, a serwer obsługuje 40 równolegle zanim zacznie się kolejkować, fala 500 prób logowania może zamienić się w wielosekundowe oczekiwania. W takim wypadku niewielkie obniżenie kosztu plus silne limity szybkości może poprawić bezpieczeństwo realne bardziej niż pchanie parametrów do punktu, w którym endpoint logowania stanie się kruchy.

Utrzymuj przewidywalność logowania interaktywnego

Nie każda operacja na haśle musi mieć taką samą pilność. Utrzymuj stabilny koszt dla logowania interaktywnego, a ciężkie prace wykonuj poza ścieżką krytyczną. Typowy wzorzec to rehash-on-login (podnoszenie hasha po udanym zalogowaniu) lub zadania w tle do migracji i importów.

Jak wybierać parametry krok po kroku

Strojenie parametrów polega na zwiększeniu kosztu dla atakującego na próbę bez spowalniania logowań czy destabilizacji serwerów.

1. Wybierz algorytm, który dobrze obsługuje twój stack. Jeśli Argon2id jest dostępny i dobrze wspierany, zwykle to domyślny wybór. Jeśli potrzebujesz szerokiej kompatybilności, bcrypt nadal wystarczy.

2. Ustal docelowy czas na hash na sprzęcie przypominającym produkcję. Wybierz coś, co utrzyma responsywność logowań podczas ruchu szczytowego.

3. Dopasuj parametry, by osiągnąć ten czas. W bcrypt zmieniasz współczynnik kosztu. W Argon2id balansujesz pamięć, iteracje i równoległość. Pamięć najbardziej wpływa na ekonomię atakującego.

4. Przechowuj algorytm i ustawienia razem z hashem. Standardowe formaty hashów zwykle zawierają te informacje. Upewnij się też, że pole w bazie jest wystarczająco długie, by hashe się nie obcinały.

5. Planuj aktualizacje z rehash-on-login. Gdy użytkownik się zaloguje i jego zapisany hash używa słabszych ustawień, ponownie go oblicz i zastąp.

Praktyczny punkt startowy

Jeśli potrzebujesz punktu wyjścia przed pomiarami, zacznij konserwatywnie i dostosuj według pomiarów.

• Dla bcrypt wiele zespołów zaczyna od kosztu ~12 i zmienia go na podstawie rzeczywistych pomiarów.
• Dla Argon2id typowy punkt startowy to pamięć w dziesiątkach do kilkuset MB, koszt czasowy (iteracje) 2–4 oraz równoległość 1–2.

Traktuj to jako punkty wyjścia, nie reguły. Właściwe ustawienia to te, które pasują do twojego ruchu, sprzętu i skoków logowań.

Częste błędy, które osłabiają przechowywanie haseł

Większość porażek w przechowywaniu haseł wynika z luk konfiguracyjnych, a nie z wad algorytmu.

Błędy z solami to duży problem. Każde hasło musi mieć własną, unikalną sól przechowywaną z hashem. Ponowne używanie soli lub globalna sól dla wszystkich użytkowników ułatwia atakującym ponowne użycie pracy i porównywanie kont.

Zaniedbanie kosztu to kolejny. Zespoły często wypuszczają niskie koszty, bo logowanie wydaje się szybsze, a potem o tym nie pamiętają. Sprzęt się poprawia, atakujący skalują się, i to, co kiedyś było wystarczające, staje się tanie.

Przetrajanie Argon2 to też powszechny problem. Ustawienie pamięci ekstremalnie wysoko może wyglądać dobrze na papierze, a potem powodować wolne logowania, kolejki i błędy OOM przy realnych skokach.

Obsługa długości hasła ma znaczenie, szczególnie z 72-bajtowym zachowaniem bcrypt. Jeśli pozwalasz na długie hasła, a ciche obcinanie je skraca, wprowadzasz zamieszanie i osłabiasz bezpieczeństwo.

Kilka praktycznych nawyków zapobiega większości problemów:

• używaj unikalnych soli dla każdego hasła (pozwól bibliotece je generować)
• testuj i przeglądaj ustawienia w regularnych odstępach
• stroń pamięć Argon2 pod kątem ruchu szczytowego, nie tylko pojedynczych testów
• jasno określaj i stosuj limity długości hasła
• nakładaj limity współbieżności i monitoruj punkt logowania

Krótka lista kontrolna dla bezpieczniejszej konfiguracji

Miej tę listę pod ręką przy wdrożeniu i przy zmianach infrastruktury:

• Unikalna sól dla każdego hasła, generowana losowo i przechowywana z hashem
• Koszt hashowania, który przetrwa ruch szczytowy, zweryfikowany testami obciążeniowymi na sprzęcie podobnym do produkcyjnego
• Parametry przechowywane z hashem, by móc weryfikować stare konta i podnosić koszty później
• Kontrole ataków online, w tym limity szybkości i krótkie blokady przy powtarzających się niepowodzeniach
• Ścieżka aktualizacji, zwykle rehash-on-login

Prosta kontrola: uruchom test na stagingu obejmujący falę logowań (udane i nieudane) i obserwuj opóźnienia end-to-end oraz użycie CPU i RAM. Jeśli ścieżka logowania słabnie, dostrój koszt i zaostrz limity szybkości. Nie „naprawiaj” problemu przez cięcie podstawowych elementów, jak sole.

Przykład z życia: strojenie dla małej aplikacji webowej

Wyobraź sobie małą aplikację SaaS z kilkoma tysiącami użytkowników. Większość dnia ruch jest stały, ale występują krótkie skoki logowań po newsletterze lub na początku dnia pracy. Tu wybór staje się planowaniem pojemności.

Wybierasz Argon2id, by zwiększyć koszt łamania offline. Ustal celowy czas weryfikacji na swoim rzeczywistym serwerze (np. 100–250 ms), następnie dostrój parametry, obserwując pamięć, bo ustawienia pamięci ograniczają liczbę jednoczesnych logowań.

Praktyczna pętla strojenia wygląda tak:

• zacznij od umiarkowanych iteracji i równoległości
• zwiększaj pamięć, aż współbieżność stanie się niewygodna
• dostosuj iteracje, by dopracować koszt czasowy
• testuj z symulowanymi falami, nie tylko pojedynczymi żądaniami

Jeśli masz starsze hashe z słabszymi ustawieniami, dalej je weryfikuj, ale aktualizuj stopniowo. Po udanym logowaniu przelicz hash z aktualnymi ustawieniami i zapisz nową wartość. Z czasem aktywni użytkownicy przejdą na silniejsze hashe bez wymuszania resetów.

Po wdrożeniu monitoruj ścieżkę logowania jak każdy inny krytyczny endpoint: tail latency (p95/p99), CPU i RAM podczas fal, skoki nieudanych logowań i tempo, w jakim stare hashe są wymieniane.

Kolejne kroki: wdrażaj bezpiecznie i ulepszaj

Zapisz swoją politykę i traktuj ją jako żywy dokument. Na przykład: „Argon2id z X pamięci, Y iteracji, Z równoległości” lub „bcrypt współczynnik kosztu N”, plus data wyboru i termin przeglądu (co 6–12 miesięcy to dobry punkt wyjścia).

Zadbaj o ścieżkę aktualizacji, żeby nie być uwięzionym przy starych hashach. Rehash-on-login jest prosty i dobrze działa w większości systemów.

Silny hash pomaga, ale nie zastępuje kontroli nadużyć online. Limity szybkości, blokady i przemyślane przepływy resetu haseł są równie ważne dla bezpieczeństwa w praktyce.

Jeśli budujesz backend na platformie no-code takiej jak AppMaster, warto sprawdzić, czy moduł uwierzytelniania używa silnych ustawień hashowania domyślnie i czy koszty są strojobane na tym samym rodzaju infrastruktury, na którym będziesz wdrażać. To niewielki wysiłek na starcie, który często decyduje między „bezpieczne i płynne” a „bezpieczne, ale nieużywalne pod obciążeniem”.