Zapisanie SHA-256 zamiast hasła wydaje się bezpieczne, bo funkcja jest jednokierunkowa. Problemem jest jej szybkość. Po kradzieży bazy atakujący nie odwraca digestu. Generuje popularne hasła, hashuje je i porównuje. Szybki algorytm pozwala sprawdzać ogromne liczby kandydatów. Password hashing działa inaczej: celowo podnosi koszt każdej próby.

Atak odbywa się offline

Login online można ograniczać rate limitem, MFA i analizą nadużyć. Kopia bazy usuwa te bariery. Atakujący korzysta z własnych GPU bez wysyłania requestów.

Ludzkie hasła mają małą entropię i powtarzalne wzorce. Ochrona musi spowolnić guessing, a nie tylko ukryć oryginalny string.

Salt rozdziela identyczne hasła

Losowy unikalny salt jest przetwarzany razem z hasłem. Dwaj użytkownicy z tym samym sekretem mają inne stored hashes. Jedna przygotowana tabela nie działa na całą bazę.

Salt nie musi być tajny. Utrzymywana biblioteka generuje go i koduje w formacie wyniku. Własny layout zwiększa ryzyko.

Algorytm ma być kosztowny z założenia

Argon2, scrypt, bcrypt i PBKDF2 pozwalają ustawić koszt. Argon2 oraz scrypt mogą wymagać znacznej pamięci, ograniczając przewagę masowo równoległego hardware.

Wielokrotne ręczne SHA-256 nie zastępuje sprawdzonego Password KDF. Parametry, salt i konstrukcja mają znaczenie.

Parametry muszą rosnąć wraz z hardware

Dzisiejszy koszt będzie za kilka lat tani. Stored format powinien zawierać algorithm i ustawienia. Po udanym loginie aplikacja może rozpoznać stary rekord i wykonać rehash.

Nie wymaga to znajomości wszystkich plaintextów. Konta nieaktywne można objąć resetem, jeżeli ryzyko tego wymaga.

Benchmark obejmuje rzeczywisty ruch

Pojedynczy hash na laptopie nie opisuje produkcji. Należy testować równoległe loginy, autoscaling i słabsze instancje. Koszt ma być najwyższy, jaki system stabilnie obsłuży.

Zbyt duże ustawienie tworzy możliwość DoS. Rate limiting i capacity planning są częścią tej samej decyzji.

Endpoint logowania potrzebuje osobnego budżetu zasobów

Password hashing zużywa CPU i pamięć przed pełnym uwierzytelnieniem klienta. Kolejki, concurrency limits i monitoring chronią pozostałą aplikację przed zalewem prób. Test obciążeniowy powinien obejmować również nieistniejące konta wykonujące reprezentatywny koszt.

Pepper dodaje osobny sekret

Server-held pepper poza bazą może utrudnić guessing, jeśli wycieknie tylko database. Potrzebuje secret managera, backupu i planu rotacji.

Nie zastępuje salt ani dobrego algorytmu. Utrata peppera może uniemożliwić każdy login, dlatego operacje są równie ważne jak teoria.

Hasło nie powinno być odzyskiwalne

Serwis wysyłający obecne hasło przechowuje je w plaintext lub odwracalnej formie. Bezpieczny system tylko weryfikuje kandydat i oferuje reset.

Reset token jest losowy, krótko ważny, jednorazowy i purpose-bound. Po zmianie należy unieważnić pozostałe tokeny oraz zgodnie z polityką sesje.

Normalizacja musi być stała

Inne trimming lub Unicode normalization przy rejestracji i logowaniu blokuje konto. Hasło jest dokładną sekwencją znaków. Jeżeli produkt ma reguły wejścia, stosuje je jawnie i identycznie.

Ciche „poprawianie” istniejącego sekretu jest ryzykowne. Password managers pozwalają obsługiwać długie i złożone wartości bez sztucznych ograniczeń.

Login nie powinien ujawniać istnienia konta

Inny komunikat lub czas dla nieznanej nazwy wspiera enumeration. System może wykonać reprezentatywny password hash także dla braku użytkownika i zwrócić neutralny błąd.

Rate limit uwzględnia konto, sieć i szerszy wzorzec. Permanent lock po kilku próbach sam może zostać wykorzystany przeciw użytkownikowi.

Screening znanych wycieków uzupełnia ochronę

Hasła znalezione w dużych breach lists warto odrzucać przy rejestracji i zmianie. Prefix lookup albo lokalna lista pozwala uniknąć wysyłania całego sekretu do zewnętrznego serwisu.

Długość i password manager są lepsze niż skomplikowany obowiązek symboli. MFA i passkeys ograniczają skutki pojedynczej kradzieży.

Proces odzyskiwania może ominąć najlepszy hash

Jeżeli support potrafi łatwo przejąć konto albo reset token pozostaje ważny przez wiele dni, mocny Argon2 nie chroni całego systemu. Recovery potrzebuje rate limitu, bezpiecznej weryfikacji oraz powiadomienia właściciela.

Po zmianie hasła wcześniejsze reset links powinny przestać działać. Polityka określa także, czy wszystkie urządzenia zostaną wylogowane i czy szczególnie wrażliwe akcje wymagają ponownego uwierzytelnienia.

Różne algorytmy mogą współistnieć podczas migracji

Stare konta mogą mieć bcrypt, nowe Argon2. Stored format wskazuje metodę, więc verifier wybiera właściwą funkcję. Po poprawnym loginie zapis jest aktualizowany bez proszenia o plaintext wcześniej.

Próba jednorazowego „przeliczenia” hashy bez hasła jest niemożliwa. Kolejny hash starego digestu nie daje takich samych właściwości jak prawidłowy rehash oryginalnego sekretu.

Konta uprzywilejowane zasługują na mocniejszy workflow

Administrator może wymagać MFA, krótszych sesji i alertu po zmianie credentials. Sam storage hasła nie ogranicza szkody po skutecznym phishingu.

Break-glass accounts powinny mieć kontrolowany dostęp, okresowe testy i audit. Wspólny sekret używany przez kilka osób uniemożliwia wiarygodne przypisanie działań.

Incydent wymaga przygotowanej reakcji

Mocny hash kupuje czas, ale nie czyni wycieku bezpiecznym. Organizacja musi znać używane algorytmy, wymusić reset według ryzyka, unieważnić sesje i monitorować credential stuffing.

Inwentarz parametrów pozwala najpierw chronić najsłabsze rekordy. Komunikacja z użytkownikami powinna być jasna i szybka.

Konta techniczne mają inny lifecycle

Jeżeli service account używa hasła, również potrzebuje silnego storage. Często lepsze są rotowane API keys, client certificates lub workload identity.

Hash nie naprawi sekretu skopiowanego do image, scriptu i kilku środowisk. Ochrona obejmuje generowanie, dystrybucję i revocation.

Password storage jest osobną dziedziną

Szybki hash tworzy fingerprint danych, a password hash broni przed guessing. Platformowa biblioteka powinna zarządzać salt, formatem i verification.

Bezpieczne rozwiązanie łączy kosztowną funkcję, rehash, reset, abuse protection i nowoczesne alternatywy dla zapamiętywanego hasła.