Przed czym naprawdę chroni haszowanie hasła

Wersja krótka

Haszowanie hasła chroni użytkowników wtedy, gdy skradziona zostanie baza danych z hasłami.

To jest jego główne zadanie. Nie jedyny szczegół, nie cały model bezpieczeństwa, ale centralny powód, dla którego haszujemy hasła zamiast przechowywać je bezpośrednio.

Prawidłowo zahaszowane hasło jest trudne do odwrócenia. Jeśli atakujący zdobędzie kopię tabeli użytkowników, nie powinien od razu dowiedzieć się, że hasło Alice to Spring2026!. Zamiast tego otrzymuje zapisany hash, którego sprawdzenie względem zgadywanych haseł wymaga czasu, pieniędzy i sprzętu.

Ta różnica ma znaczenie. Haszowanie haseł nie ma samo w sobie zabezpieczać logowania. Nie zatrzymuje phishingu. Nie zatrzymuje kogoś, kto próbuje używać wyciekłych haseł w formularzu logowania. Nie chroni ciasteczka sesyjnego po zalogowaniu. Kupuje czas i zmniejsza szkody po bardzo konkretnym błędzie: ujawnieniu magazynu weryfikatorów haseł.

Jeśli rozumiesz tę granicę, będziesz podejmować lepsze decyzje dotyczące algorytmów, współczynników kosztu, resetów, logowania i reakcji na incydenty.

Czym jest hash hasła

Hash hasła to wynik działania funkcji jednokierunkowej zastosowanej do hasła, zwykle z unikalną solą i celowo wolnym algorytmem haszowania haseł.

Gdy użytkownik tworzy konto, system powinien zrobić mniej więcej to:

1. Odebrać hasło przez HTTPS.
2. Wygenerować losową, unikalną sól.
3. Przepuścić hasło i sól przez funkcję haszowania haseł, taką jak Argon2id, bcrypt, scrypt lub PBKDF2.
4. Zapisać nazwę algorytmu, parametry, sól i wynikowy hash.
5. Odrzucić oryginalne hasło.

Gdy użytkownik loguje się później, system powtarza ten sam proces haszowania z podanym hasłem i zapisanymi parametrami. Jeśli wynikowy hash pasuje do zapisanego hasha, logowanie się udaje.

Ważne jest to, że aplikacja nie musi znać oryginalnego hasła. Musi tylko zweryfikować, że podane hasło daje oczekiwany wynik.

Dlatego przechowywanie haseł za pomocą odwracalnego szyfrowania jest zwykle niewłaściwym modelem. Jeśli aplikacja może odszyfrować każde hasło, to każdy, kto ukradnie klucz deszyfrujący, może zrobić to samo. Hasła normalnie powinny być nieweryfikowalne wstecz, a nie jedynie ukryte.

Przed czym chroni haszowanie

1. Natychmiastowe ujawnienie haseł po naruszeniu bazy danych

Jeśli atakujący ukradnie bazę danych zawierającą hasła w postaci jawnej, szkoda jest natychmiastowa. Każde hasło zostaje ujawnione. Użytkownicy są zagrożeni nie tylko w Twoim serwisie, ale wszędzie tam, gdzie użyli ponownie tego hasła.

Jeśli baza danych zawiera dobrze zahaszowane hasła, atakujący ma więcej pracy. Musi zgadywać kandydatów na hasła, haszować każdą próbę z właściwą solą i parametrami, a następnie porównywać wynik.

W przypadku słabych haseł nadal może to być szybkie. W przypadku silnych, unikalnych haseł może być niepraktyczne.

Haszowanie zamienia katastrofalne ujawnienie w wyścig: czy użytkownicy zdążą zresetować hasła i czy zdołasz opanować incydent, zanim atakujący złamią wiele z nich?

To nie jest doskonałe. To wciąż naruszenie. Ale jest to dramatycznie lepszy tryb awarii.

2. Ataki masowe na całą bazę użytkowników

Sole są kluczową częścią przechowywania haseł, ponieważ uniemożliwiają atakującym efektywne atakowanie wielu użytkowników naraz za pomocą wstępnie obliczonych tabel.

Sól nie jest tajna. Jest przechowywana obok hasha. Jej zadaniem jest unikalność.

Jeśli dwóch użytkowników wybierze to samo hasło, unikalne sole sprawią, że ich zapisane hashe będą się różnić. Uniemożliwia to atakującym szybkie zauważenie, że wielu użytkowników ma to samo hasło. Zapobiega też klasycznym atakom z użyciem rainbow tables, w których atakujący wykorzystują ogromne, wstępnie obliczone listy mapowań hasło-hash.

Bez soli jeden złamany hash może ujawnić każdego użytkownika z tym samym hasłem. Z solami każda próba hasła musi być testowana osobno dla każdego użytkownika.

3. Szybkie zgadywanie offline

Gdy atakujący mają bazę haseł, mogą zgadywać offline. Oznacza to, że limity prób logowania, CAPTCHA, blokowanie IP i monitoring przestają mieć znaczenie. Atakujący może testować próby na własnym sprzęcie.

W tym miejscu znaczenie ma wybór algorytmu.

Hashe ogólnego przeznaczenia, takie jak SHA-256 i SHA-512, są projektowane tak, aby były szybkie. To dobre dla integralności plików i podpisów cyfrowych. To złe dla przechowywania haseł.

Algorytmy haszowania haseł są projektowane tak, aby były wolne, konfigurowalne, a czasem także pamięciożerne. Argon2id, bcrypt, scrypt i PBKDF2 pozwalają dostosowywać parametry kosztu tak, aby każda próba zajmowała znaczący czas.

Argon2id jest szeroko rekomendowany dla nowych systemów, ponieważ można go skonfigurować tak, aby wymagał zarówno czasu CPU, jak i pamięci, co podnosi koszt łamania na dużą skalę przy użyciu GPU. bcrypt pozostaje powszechny i akceptowalny przy dobrej konfiguracji, choć ma ograniczenia, takie jak obsługa długości hasła. PBKDF2 nadal jest używany w niektórych środowiskach podporządkowanych wymogom zgodności, szczególnie tam, gdzie wymagane są komponenty z walidacją FIPS.

Zasada jest prosta: sprawić, by legalne logowania były akceptowalnie szybkie, a miliardy prób — kosztowne.

Przed czym haszowanie nie chroni

1. Phishing

Jeśli użytkownik wpisze hasło na fałszywej stronie logowania, haszowanie na Twoim serwerze nie pomoże. Atakujący otrzymuje hasło, zanim Twój system w ogóle je zobaczy.

Obrony są tutaj inne: uwierzytelnianie wieloskładnikowe, passkeys, edukacja użytkowników, higiena domen, uwierzytelnianie odporne na phishing i starannie zaprojektowane przepływy resetowania hasła.

Haszowanie haseł jest zabezpieczeniem awaryjnym dla przechowywanych sekretów. Nie jest obroną przed tym, że użytkownicy zostaną podstępem skłonieni do oddania tych sekretów.

2. Credential stuffing

Credential stuffing występuje, gdy atakujący biorą pary nazwa użytkownika i hasło wyciekłe z jednej usługi i próbują ich w innej.

Twoje hashe haseł mogą być doskonałe, a credential stuffing nadal może działać, jeśli użytkownicy ponownie używają haseł.

To atak online na formularz logowania, a nie atak offline na bazę danych. Potrzebujesz limitowania prób, wykrywania anomalii, sprawdzania haseł znanych z wycieków, MFA i rozsądnych zasad blokad, które nie tworzą łatwych okazji do ataków odmowy usługi.

To samo praktyczne myślenie dotyczy każdego wystawionego formularza. Jeśli przeglądasz powierzchnię uwierzytelniania, warto przeczytać, dlaczego formularz kontaktowy jest Twoim największym źródłem ryzyka spamu; mechanika jest inna, ale lekcja podobna: publiczne wejścia potrzebują kontroli nadużyć, a nie tylko czystego kodu backendu.

3. Hasła przechwycone w logach lub analityce

Haszowanie pomaga tylko wtedy, gdy hasło w postaci jawnej jest szybko odrzucane i nigdy nie kopiowane gdzie indziej.

Typowe błędy obejmują:

• Logowanie pełnych treści żądań przy nieudanych próbach logowania.
• Wysyłanie haseł do narzędzi monitorowania błędów.
• Przechwytywanie pól haseł w produktach do odtwarzania sesji.
• Umieszczanie poświadczeń w URL-ach podczas źle zaprojektowanych przepływów resetu lub migracji.
• Przechowywanie tymczasowych haseł w postaci jawnej podczas importów.

Te błędy całkowicie omijają haszowanie haseł. Jeśli tekst jawny trafi do logów, kopii zapasowych, hurtowni danych lub narzędzi firm trzecich, funkcja haszująca jest bez znaczenia.

Traktuj pola haseł jak dane toksyczne. Redaguj je przed logowaniem. Wykluczaj je z analityki. Trzymaj je z dala od URL-i. Ogranicz dostęp do śladów produkcyjnych.

4. Słabe zabezpieczenie sesji

Po zalogowaniu przeglądarka użytkownika zwykle otrzymuje ciasteczko sesyjne lub token. Jeśli ten token zostanie skradziony, atakujący może w ogóle nie potrzebować hasła.

Haszowanie haseł nie chroni przed cross-site scripting, niezabezpieczonymi ciasteczkami, session fixation, słabym generowaniem tokenów ani zbyt długim czasem życia sesji.

Ciasteczka sesyjne zasługują na osobny przegląd: HttpOnly, Secure, odpowiednie SameSite, krótkotrwałe sesje wysokiego ryzyka i unieważnianie po stronie serwera przy zmianach hasła. Szerszy krajobraz prywatności i przeglądarek również stale się zmienia, jak opisano w artykule co zmieniło się w ciasteczkach w 2026 roku.

5. Słabe resetowanie hasła i odzyskiwanie konta

Wiele przejęć kont nie zaczyna się od hasła. Zaczyna się od procesu resetowania.

Jeśli tokeny resetujące są przewidywalne, długowieczne, wyciekają przez nagłówki referrer lub są wysyłane na przejęte konta e-mail, haszowanie haseł Cię nie uratuje.

Używaj tokenów resetujących o wysokiej entropii, krótkich okien ważności, jednorazowego użycia i czytelnych powiadomień dla użytkowników. Ponieważ e-mail często jest kanałem odzyskiwania, podstawowe uwierzytelnianie domeny również ma znaczenie. Jeśli Twój zespół traktuje rekordy DNS jak tajemniczy rytuał, zacznij od przystępnego dla deweloperów przewodnika po MX, SPF, DKIM i DMARC.

Wybór algorytmu: czego używać teraz

Dla nowych aplikacji używaj Argon2id, jeśli Twoja platforma dobrze go obsługuje. To zwycięzca Password Hashing Competition i algorytm zaprojektowany do przechowywania haseł, w tym z odpornością na łamanie intensywnie wykorzystujące GPU.

Rozsądna współczesna hierarchia wygląda tak:

1. Argon2id dla nowych systemów, gdy jest dostępny.
2. bcrypt gdy Argon2id nie jest praktyczny, a obsługa bcrypt jest dojrzała.
3. scrypt gdy konfiguracja pamięciożerna jest dobrze wspierana.
4. PBKDF2 gdy wymagają tego ograniczenia platformy lub zgodności.

Unikaj zwykłego SHA-256, SHA-512, MD5 albo własnej kombinacji typu sha256(password + salt). Szybkie hashe nie są funkcjami do przechowywania haseł. Sprytne konstrukcje własne zwykle są gorsze niż nudne, standardowe rozwiązania.

Unikaj też wymyślania własnej polityki haseł opartej na szczegółach algorytmów. Użytkownicy nie korzystają na liście 12 zasad składu hasła, jeśli popycha ich ona ku przewidywalnym wzorcom. Dłuższe, unikalne hasła, menedżery haseł, sprawdzanie haseł z wycieków i MFA zwykle mają większe znaczenie.

Współczynniki kosztu nie są ustawiane raz na zawsze

Haszowanie haseł ma parametry. Argon2id ma pamięć, iteracje i równoległość. bcrypt ma współczynnik kosztu. PBKDF2 ma liczbę iteracji.

Te wartości należy dobierać na podstawie środowiska produkcyjnego. Zbyt niskie — a atakujący zgadują tanio. Zbyt wysokie — a system logowania staje się wolny lub podatny na odmowę usługi.

Praktyczny cel często mieści się w zakresie od dziesiątek do kilku setek milisekund na weryfikację hasła na rzeczywistych serwerach, zależnie od ruchu i ryzyka. Systemy wysokiego bezpieczeństwa mogą wybrać więcej. Systemy konsumenckie na dużą skalę mogą wymagać starannego planowania pojemności.

Nie kopiuj współczynnika kosztu z pięcioletniego wpisu na blogu. Sprzęt się zmienia. Biblioteki się zmieniają. Ruch się zmienia.

Okresowo przeglądaj parametry i planuj ponowne haszowanie. Częstym wzorcem jest przechowywanie algorytmu i parametrów z każdym hashem. Przy udanym logowaniu, jeśli zapisane parametry są przestarzałe, zahaszuj ponownie podane hasło z nowszą konfiguracją i zaktualizuj rekord.

Peppers: użyteczne, ale nie jako zamiennik

Pepper to tajna wartość dodawana do procesu haszowania hasła i przechowywana osobno od bazy danych, często w menedżerze sekretów lub sprzętowym module bezpieczeństwa.

W przeciwieństwie do soli pepper musi pozostać tajny.

Peppers mogą zmniejszyć szkody, jeśli wycieknie baza danych, ale sekrety aplikacji nie. Są najbardziej przydatne w dojrzałych środowiskach z dobrym zarządzaniem kluczami. Są mniej przydatne, jeśli ten sam atakujący może ukraść zarówno bazę danych, jak i konfigurację aplikacji.

Jeśli używasz peppera, starannie zaplanuj rotację. Jego rotacja może wymagać, aby użytkownicy zalogowali się ponownie lub zresetowali hasła, zależnie od projektu. Pepper jest dodatkową warstwą, a nie powodem do osłabienia podstawowych ustawień hasha.

Lista kontrolna operacyjna

Jeśli odpowiadasz za prawdziwy system, praktyczna lista kontrolna jest krótka:

• Przechowuj hasła wyłącznie przy użyciu standardowego algorytmu haszowania haseł.
• Używaj unikalnej, losowej soli dla każdego hasła.
• Preferuj Argon2id w nowych wdrożeniach.
• Dostrajaj parametry kosztu na sprzęcie podobnym do produkcyjnego.
• Przechowuj algorytm i parametry z każdym hashem.
• Haszuj ponownie przy logowaniu, gdy parametry stają się przestarzałe.
• Nigdy nie loguj haseł ani nie wysyłaj ich do narzędzi analitycznych.
• Używaj TLS wszędzie tam, gdzie przesyłane są poświadczenia.
• Dodaj MFA lub passkeys tam, gdzie ryzyko to uzasadnia.
• Chroń przepływy resetowania tak poważnie jak przepływy logowania.
• Miej plan incydentowy dla wymuszonych resetów i powiadamiania użytkowników.

Haszowanie haseł nie jest efektowne. To instalacja techniczna. Ale to taki rodzaj instalacji, który decyduje, czy naruszenie stanie się bolesnym incydentem, czy katastrofą obejmującą wszystkich użytkowników.

<!-- tool-cta:start -->

💡 Wypróbuj to: Zobacz, jak to samo wejście jest mapowane na różne algorytmy za pomocą Hash Generator, który konkretnie pokazuje różnicę między szybkimi hashami a hashami klasy haseł.

<!-- tool-cta:end -->

Uczciwy model mentalny

Najlepiej myśleć o haszowaniu haseł tak:

Haszowanie nie chroni hasła, gdy użytkownik je wpisuje. Nie chroni konta po zalogowaniu użytkownika. Nie chroni użytkowników, którzy ponownie używają haseł w różnych miejscach w sieci.

Chroni przechowywany weryfikator.

Brzmi wąsko, ale jest niezwykle ważne. Bazy danych wyciekają. Kopie zapasowe wyciekają. Systemy stagingowe są kopiowane. Dostawcy otrzymują dostęp, którego nie powinni mieć. Stare eksporty leżą w object storage dłużej, niż ktokolwiek pamięta.

Gdy to się stanie, projekt przechowywania haseł decyduje o różnicy między tym, czy atakujący otrzymają hasła, czy kosztowny problem zgadywania.

Właśnie przed tym naprawdę chroni haszowanie hasła.