Przechowuj hasła z użyciem Argon2id, ustawionego na co najmniej 19 MiB pamięci, 2 iteracje i 1 stopień równoległości, z unikalną solą dla każdego hasła. To minimalna konfiguracja z OWASP Password Storage Cheat Sheet. Jeśli w Twojej bazie nadal są hashe MD5, SHA-1 lub hashe bez soli, możesz to naprawić bez masowego resetu haseł i bez zostawiania słabych hashy przy uśpionych kontach.
Czego używać i jakie są minimalne ustawienia
Cheat sheet podaje takie minima:
| Sytuacja | Algorytm | Minimalne ustawienia |
|---|---|---|
| Rozwiązanie preferowane | Argon2id | 19 MiB pamięci, 2 iteracje, równoległość 1 |
| Argon2id niedostępny | scrypt | parametr kosztu 2^17, rozmiar bloku 8, równoległość 1 |
| Starsze systemy na bcrypt | bcrypt | work factor 10 lub więcej, limit hasła 72 bajty |
| Wymagana zgodność z FIPS-140 | PBKDF2 | 600 000 lub więcej, HMAC-SHA-256 |
Argon2id to podstawowy wariant w RFC 9106, a każda implementacja tego dokumentu musi go obsługiwać. Przez pierwszą połowę pierwszego przebiegu po pamięci działa jak Argon2i, a przez resztę jak Argon2d.
Limit 72 bajtów w bcrypt
Cheat sheet wyznacza dla bcrypt limit hasła na 72 bajty. Źródła nie mówią, jak poszczególne biblioteki traktują dłuższe dane wejściowe, więc przetestuj swoją. Zahashuj hasło złożone z 72 znaków a i znaku b na końcu, a następnie zweryfikuj hasło złożone z 72 znaków a i znaku c na końcu. Jeśli weryfikacja się powiedzie, Twoja biblioteka po cichu obcina hasło.
Potem albo ogranicz długość hasła w formularzach do 72 bajtów i jasno o tym poinformuj, albo zaplanuj przejście na Argon2id. RFC 9106 dopuszcza hasła do 2^32-1 bajtów.
Dlaczego szybkie hashe zawodzą
MD5 i SHA-1 zaprojektowano jako szybkie, a SHA-256 z tego samego powodu się nie nadaje: pozwala atakującemu szybko wykonać ogromną liczbę prób. Atakujący hashuje kandydatów z wyciekłych list haseł, słowników lub brute force i porównuje wyniki z Twoimi rekordami. GPU i wynajmowane serwery w chmurze sprawiają, że jest to tanie.
Unikalna sól zmusza atakującego do łamania hashy jeden po drugim. Unieszkodliwia też tęczowe tablice, a identyczne hasła przestają dawać identyczne hashe. RFC 9106 zaleca 16-bajtową sól przy hashowaniu haseł. Dojrzałe biblioteki same generują i zapisują sól, więc nie pisz tej części ręcznie.
Dobór work factora
Nie ma uniwersalnej liczby. Zależy ona od Twojego serwera i liczby użytkowników, a znajdziesz ją eksperymentalnie na sprzęcie, na którym pracujesz. Ogólna zasada jest taka, że jeden hash powinien liczyć się krócej niż sekundę.
Zbyt wysokie ustawienie ma swoją cenę. Każda próba logowania zużywa CPU, a fala prób może wyczerpać zasoby serwera. Wykonaj benchmark przy realistycznej współbieżności i wybierz wartość, na którą stać Cię przy szczycie obciążenia.
Sprawdź, w jakiej jednostce oczekuje danych Twoja biblioteka Argon2. RFC 9106 definiuje rozmiar pamięci w kibibajtach, a cheat sheet podaje MiB. 19 MiB to 19456 KiB, a przekazanie 19 tam, gdzie biblioteka oczekuje KiB, daje 19 KiB pamięci. Takie ustawienie działa i jest znacznie słabsze, niż zamierzałeś.
Work factor jest zwykle zapisany w wyniku hashowania. Pomaga to w migracji, bo przy logowaniu widać, z jakimi parametrami utworzono dany hash.
Pepper jako dodatkowa warstwa
Pepper to sekret wspólny dla wszystkich przechowywanych haseł, trzymany poza bazą danych, w sejfie sekretów lub w HSM. Pomaga, gdy atakujący zdobywa tylko bazę danych, na przykład przez SQL injection lub skradzioną kopię zapasową. Sam w sobie niczego nie daje, więc traktuj go jako element obrony warstwowej.
Problemem jest rotacja. Skompromitowanego peppera nie można zmienić bez znajomości hasła każdego użytkownika, więc jego wymiana wymusza reset dla wszystkich, których chronił. Zanim wprowadzisz pepper, ustal, kto odpowiada za tę procedurę.
Migracja starych hashy
Podejście z cheat sheetu do podnoszenia work factora polega na tym, by poczekać do kolejnego uwierzytelnienia użytkownika, a potem ponownie zahashować jego hasło z nowymi ustawieniami. Przejście z MD5, SHA-1 lub hashy bez soli opiera się na tej samej logice, choć to rozszerzenie pochodzi od nas.
- Oznacz każdy zapisany hash algorytmem, w osobnej kolumnie lub przez format hasha. Jeśli nie masz pewności, co jest w tabeli, pomoże Ci identyfikator hashy, który rozpoznaje formaty.
- Przy logowaniu weryfikuj hasło algorytmem, którego używa zapisany hash.
- Po udanej weryfikacji, jeśli hash jest stary lub ma parametry słabsze od bieżących, oblicz nowy hash Argon2id z przesłanego hasła, ze świeżą solą.
- Nadpisz starą wartość w tej samej operacji.
ok = verify(row.scheme, row.hash, submitted)
if ok and (row.scheme != "argon2id" or needs_rehash(row.hash)):
row.hash = argon2id_hash(submitted) # fresh salt, current parameters
row.scheme = "argon2id"
save(row)Uśpione konta
Użytkownicy, którzy już nigdy się nie zalogują, nigdy nie zostaną zmigrowani, więc ich słabe hashe będą leżeć w tabeli w nieskończoność. Jednym z rozwiązań jest opakowanie ich teraz. Uruchom Argon2id na istniejącej wartości MD5 lub SHA-1, zapisz wynik ze znacznikiem schematu, takim jak argon2id(md5), a goły hash usuń.
Przy logowaniu obliczasz stary hash z przesłanego hasła, weryfikujesz go względem opakowania Argon2id, a po sukcesie zastępujesz opakowanie zwykłym hashem Argon2id. Zapisz dokładnie, jak zakodowana jest stara wartość (hex czy surowe bajty), ponieważ niezgodność zepsuje każde logowanie dla tego schematu. Najpierw przetestuj ścieżkę z opakowaniem na kopii tabeli.
Opakowanie nie czyni słabego hasła silnym. Chroni jedynie przed atakowaniem skradzionej tabeli z prędkością MD5.
Alternatywą jest usunięcie starych hashy po określonym terminie i wymuszenie resetu przy następnym logowaniu, co cheat sheet opisuje jako opcję zależną od aplikacji. Jeśli zmiana dotyczy kodu, nad którym nie masz pełnej kontroli, nasz zespół bezpiecznego wytwarzania oprogramowania może ją zweryfikować.
Od czego zacząć
- Przeprowadź audyt tabeli użytkowników: jakie algorytmy, czy istnieją sole i czy jakiekolwiek hasła są zapisane jawnym tekstem lub szyfrowane w sposób odwracalny. Szyfrowanie jest dopuszczalne tylko tam, gdzie musisz odzyskać oryginalne hasło, a cheat sheet każe unikać takiej potrzeby.
- Wybierz Argon2id z co najmniej 19456 KiB, 2 iteracjami i równoległością 1 i wykonuj benchmark na sprzęcie produkcyjnym, aż jeden hash będzie liczył się krócej niż sekundę.
- Jeśli używasz bcrypt, wykonaj powyższy test 72 bajtów i zdecyduj między limitem długości a przejściem na Argon2id.
- Dodaj do schematu znacznik algorytmu, zmień kod logowania tak, by weryfikował starym schematem i po sukcesie hashował ponownie.
- Opakuj pozostałe stare hashe w Argon2id albo ustal termin, po którym zostaną usunięte i wymagany będzie reset.
- Jeśli dodajesz pepper, przechowuj go w sejfie sekretów i najpierw spisz procedurę rotacji i wymuszonego resetu.
