pieprz

Pieprz (pepper) to tajna wartość wspólna dla wszystkich haseł w systemie, dokładana przy ich haszowaniu i przechowywana osobno od bazy z hashami. OWASP opisuje go jako warstwę obrony w głąb: w odróżnieniu od soli, unikalnej dla każdego hasła, pieprz jest jeden dla całej aplikacji i nie powinien być ani jawny, ani zapisany obok wygenerowanego hasha ^[1]. Celem jest to, by sam wyciek bazy danych nie wystarczył do łamania haseł. W polskich tekstach o bezpieczeństwie termin „pieprz” pojawia się obok „solenia”, na przykład w tytule artykułu Sekuraka ^[7].

Jak działa

Hasło przechodzi przez wolną funkcję haszującą z solą, a pieprz dodaje do tego krok zależny od sekretu, którego nie ma w bazie. OWASP wymienia dwa sposoby ^[1]:

• przed haszowaniem — pieprz dołącza się do hasła, zanim trafi ono do funkcji haszującej;
• po haszowaniu — gotowy hash przetwarza się funkcją HMAC, w której pieprz jest kluczem.

HMAC to mechanizm uwierzytelniania wiadomości zbudowany na funkcji skrótu (hash function) i wspólnym tajnym kluczu ^[3]. NIST w wytycznych SP 800-63B zaleca to samo w innych słowach: weryfikator powinien wykonać dodatkową iterację operacji haszowania z kluczem albo szyfrowania, używając tajnego klucza znanego tylko jemu ^[2]. Klucz ten musi być przechowywany oddzielnie od hashy haseł i powinien być używany w sprzętowo chronionym obszarze, takim jak HSM albo zaufane środowisko wykonawcze ^[2].

Oba warianty mają ten sam cel, ale różnią się szczegółami. Przy dołączaniu pieprzu przed haszowaniem trzeba pilnować ograniczeń samej funkcji, na przykład limitu 72 bajtów w bcrypt ^[1]. Wariant z HMAC po haszowaniu pozostawia wolną funkcję bez zmian i dokłada osobny krok z kluczem, co odpowiada opisowi NIST ^[2]. Pieprz nie zmienia też wymagań wobec soli: NIST wymaga soli o długości co najmniej 32 bitów, dobranej tak, by ograniczyć powtórzenia wśród zapisanych hashy ^[2].

Wariant „po haszowaniu” pokazuje schemat poniżej.

RYS. 1Hash hasła z solą i pieprzem

Sól a pieprz

Pieprz nie zastępuje soli ani wolnej funkcji haszującej, tylko je uzupełnia. Różnice zestawia tabela.

Ostatni wiersz wynika z budowy mechanizmu. OWASP zaznacza, że pieprzu nie da się wymienić bez znajomości oryginalnych haseł, więc zmiana pieprzu oznacza reset haseł użytkowników ^[1]. To odróżnia go od zwykłej rotacji kluczy szyfrujących.

W WordPressie

Rdzeń WordPressa nie używa pieprzu do haseł użytkowników. Od wersji 6.8 hasła są haszowane algorytmem bcrypt z wcześniejszym skrótem SHA-384, który ma obejść limit 72 bajtów bcrypt ^[4]. W kodzie funkcji wp_hash_password() ten wstępny skrót jest liczony jako HMAC z kluczem wp-sha384 ^[5]. Komentarz w kodzie wyjaśnia, że klucz służy separacji domen ^[5]. Jest to stała zapisana w publicznym kodzie źródłowym, więc nie spełnia warunku tajności i nie jest pieprzem.

Pieprzem nie są też klucze bezpieczeństwa i sole z pliku wp-config.php. Dokumentacja opisuje je jako wartości, których zmiana unieważnia wszystkie istniejące ciasteczka i wymusza ponowne logowanie ^[6]. Dotyczą więc sesji, a nie zapisanych hashy haseł. Podobnie jest z innymi sekretami rdzenia: od wersji 6.8 hasła aplikacji i klucze resetowania hasła są haszowane szybkim algorytmem BLAKE2b przez bibliotekę Sodium ^[4], również bez pieprzu.

Pieprz można dodać we własnym zakresie. Funkcja wp_hash_password() jest wymienialna: wtyczka może ją zastąpić własną implementacją ^[5]. Taka zmiana wymaga też odpowiednika przy weryfikacji hasła i planu na przyszłą wymianę sekretu. Wartość pieprzu powinna leżeć poza bazą, na przykład w zmiennej środowiskowej albo w systemie zarządzania sekretami, a nie w tabeli opcji. Przykład obronny w PHP:

// Pieprz spoza bazy danych, np. ze zmiennej środowiskowej.
$pepper = getenv( 'APP_PASSWORD_PEPPER' );
$peppered = base64_encode( hash_hmac( 'sha384', $password, $pepper, true ) );
$hash = password_hash( $peppered, PASSWORD_BCRYPT );

Kodowanie base64 wyniku HMAC odpowiada zaleceniu OWASP: przy łączeniu bcrypt ze wstępnym haszowaniem surowe bajty mogą zawierać bajt zerowy, na którym bcrypt obcina dane ^[1].

Znaczenie

Pieprz ma sens w scenariuszu, w którym atakujący zdobył kopię bazy, na przykład przez wstrzyknięcie SQL albo wyciek kopii zapasowej, ale nie ma dostępu do plików konfiguracyjnych ani do HSM. Wtedy hashe są bezużyteczne do ataku siłowego (brute force), bo bez pieprzu nie da się sprawdzić żadnego kandydata na hasło. Jeśli atakujący przejął cały serwer, pieprz zwykle nie chroni, bo aplikacja musi go znać, żeby weryfikować logowania. Dlatego NIST wskazuje sprzętowo chroniony obszar jako właściwe miejsce dla tego klucza ^[2].

Dobre praktyki

• Najpierw wolna, solona funkcja haszująca; pieprz to dodatek, nie podstawa ^[1].
• Pieprz przechowywany oddzielnie od hashy ^[2], najlepiej w HSM albo sejfie sekretów ^[1].
• Pieprz generowany losowo i odpowiednio długi, tak jak klucz kryptograficzny, a nie wymyślony przez człowieka.
• Wersjonowanie pieprzu w zapisie hasha, żeby dało się wprowadzić nowy bez natychmiastowego resetu wszystkich kont.
• Pieprz nigdy nie trafia do repozytorium kodu; zaszyty sekret to osobny problem opisany w haśle zaszyte w kodzie hasło.