Dlaczego SHA-256 nie wystarcza do przechowywania haseł
Hash pliku i zapis hasła na serwerze mają różne wymagania. Dla haseł liczy się również koszt każdej próby odgadnięcia.
W tym poradniku
Hashowanie nie jest szyfrowaniem. Szyfrogram można odszyfrować właściwym kluczem. Funkcja skrótu nie oferuje analogicznej operacji odwracania. Nie znaczy to jednak, że hasło zapisane jako skrót pozostaje poza zasięgiem napastnika.
Po wycieku bazy atakujący może zgadywać hasła lokalnie: obliczać wynik dla każdej propozycji i porównywać go z ukradzionym zapisem. Nie musi przy tym przechodzić przez limit prób logowania Twojej aplikacji.
Szybkość SHA staje się wadą
SHA-256 świetnie nadaje się do wielu zastosowań kryptograficznych, w tym sprawdzania integralności. Zaprojektowano go do szybkiego przetwarzania danych. Dla przechowywania haseł chcemy natomiast, aby każda próba kosztowała napastnika zauważalne zasoby.
Dodanie soli do SHA256(sól + hasło) nie rozwiązuje problemu szybkości. Sól i koszt obliczeń pełnią różne role. Nie zastępuj wyspecjalizowanej funkcji własną pętlą skrótów ani nie projektuj własnego formatu poświadczeń.
Użyj biblioteki do hashowania haseł
Dla nowego rozwiązania OWASP wskazuje Argon2id jako preferowany wybór. Scrypt jest alternatywą, gdy Argon2id jest niedostępny. PBKDF2 ma zastosowania między innymi w środowiskach z określonymi wymaganiami zgodności. Bcrypt bywa potrzebny w starszych systemach, ale ma ograniczenia, w tym długości wejścia.
Wybierz utrzymywaną bibliotekę z funkcjami tworzenia i weryfikacji zapisu. Powinna obsługiwać generowanie soli i przechowywanie parametrów. Parametry kosztu dobierz według aktualnych zaleceń oraz pomiarów na docelowym serwerze, uwzględniając równoległe logowania i limity zasobów.
Wysoki koszt jednej operacji nie może pozwalać na łatwe przeciążenie usługi. Ochrona online nadal wymaga ograniczania prób i kontroli obciążenia.
Sól, parametry i pepper
Sól jest losową wartością osobną dla każdego zapisu. Nie musi być tajna. Dzięki niej te same hasła nie dają identycznych zapisów, a praca wykonana dla jednego rekordu nie przenosi się bezpośrednio na wszystkie pozostałe.
W bazie zachowujesz również identyfikator algorytmu i parametry potrzebne do weryfikacji. Biblioteki często umieszczają je razem w jednym zakodowanym ciągu.
Pepper to opcjonalny dodatkowy sekret przechowywany poza bazą haseł. Może pomóc w określonych scenariuszach wycieku, ale utrudnia zarządzanie kluczami i rotację. Nie jest zamiennikiem soli ani poprawnej funkcji hashowania.
Jak podnosić koszt bez znajomości haseł?
Przy udanym logowaniu aplikacja ma chwilowo hasło podane przez użytkownika. Najpierw weryfikuje je według starego zapisu, a następnie — jeśli parametry są nieaktualne — tworzy nowy zapis z bieżącymi ustawieniami. To typowy moment na rehash.
Nie odzyskasz oryginalnego hasła z dotychczasowego skrótu, żeby przeliczyć całą bazę. Dla kont, które nie wracają do usługi, potrzebna jest osobna polityka migracji lub wymuszenia resetu. Aktualizacja parametrów nie cofa też skutków wcześniejszego wycieku.
Przed wdrożeniem sprawdź odrzucanie błędnego hasła, migrację starego rekordu, limity długości i zachowanie przy obciążeniu. Nie loguj haseł ani nie wysyłaj ich do narzędzi analitycznych podczas tych testów.