klucze bezpieczeństwa i sole

Klucze bezpieczeństwa i sole to osiem stałych w pliku wp-config.php, które zawierają długie losowe ciągi: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY oraz odpowiadające im AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT i NONCE_SALT ^[1]. WordPress używa ich jako tajnego materiału przy podpisywaniu ciasteczek logowania i tokenów nonce ^[2]. Dokumentacja opisuje ich rolę krótko: tajny klucz utrudnia skuteczny atak, bo dodaje losowe elementy ^[1]. Wartości nie trzeba pamiętać; mają być długie, losowe i skomplikowane ^[1].

Jak działa

Każda para klucz i sól obsługuje jeden schemat. Funkcja wp_salt() zna cztery schematy: auth, secure_auth, logged_in i nonce ^[2]. Dla wybranego schematu łączy klucz z solą i zwraca materiał, z którego wp_hash() liczy podpis ^[2]. W ten sposób ciasteczko logowania po HTTP, ciasteczko po HTTPS, ciasteczko „zalogowany” i tokeny nonce mają osobne sekrety.

Ciasteczko logowania powstaje w funkcji wp_generate_auth_cookie(). Najpierw wp_hash() wylicza klucz z nazwy użytkownika, fragmentu skrótu hasła, czasu wygaśnięcia i tokenu sesji, z użyciem schematu ciasteczka ^[3]. Potem HMAC-SHA256 tym kluczem podpisuje nazwę użytkownika, czas wygaśnięcia i token ^[3]. Gotowe ciasteczko ma postać login|wygaśnięcie|token|podpis ^[3]. Przy każdym żądaniu WordPress liczy podpis ponownie i porównuje go z tym w ciasteczku. Kolejne kroki pokazuje schemat poniżej.

RYS. 1Od kluczy do podpisu ciasteczka logowania

Tokeny nonce działają podobnie. wp_create_nonce() wylicza je przez wp_hash() ze schematem nonce z przedziału czasu, nazwy akcji, identyfikatora użytkownika i tokenu sesji ^[4]. Bez znajomości NONCE_KEY i NONCE_SALT nie da się przewidzieć poprawnego tokenu dla cudzej sesji.

Składniki

Nazwa „sól” pochodzi z kryptografii, gdzie sól to losowa wartość dodawana do danych przed liczeniem skrótu. W WordPressie klucz i sól pełnią wspólnie rolę sekretu dla funkcji HMAC, czyli są w praktyce kluczem kryptograficznym podzielonym na dwie części.

W WordPressie

Klucze generuje instalator albo administrator. Dokumentacja zaleca oficjalny generator pod adresem api.wordpress.org/secret-key/1.1/salt/ ^[1], który przy każdym wywołaniu zwraca gotowe osiem linii define() z nowymi wartościami ^[5]. Fragment pliku wygląda tak (wartości skrócone):

define( 'AUTH_KEY',        'długi losowy ciąg' );
define( 'SECURE_AUTH_KEY', 'inny długi losowy ciąg' );
// ... sześć kolejnych stałych

Gdy stała nie jest zdefiniowana albo zawiera domyślny tekst put your unique phrase here, wp_salt() generuje 64-znakową wartość i zapisuje ją w opcjach bazy danych ^[2]. Strona działa dalej, ale sekret leży wtedy w bazie, a nie w pliku konfiguracyjnym. Wyciek bazy, na przykład przez SQL injection, ujawnia w takim układzie także materiał do podrabiania ciasteczek. Klucze są częścią szerszego tematu, jakim jest utwardzanie pliku wp-config.php. Ten sam plik zawiera hasło do bazy danych, dlatego ma znaczenie ochrona przed jego odczytem, na przykład przez odpowiednie uprawnienia plików i blokadę dostępu z sieci.

Znaczenie

Klucze są tą częścią podpisu ciasteczka, której nie da się wyczytać z konta użytkownika. Podpis zależy od kluczy, od fragmentu skrótu hasła i od tokenu sesji ^[3]; dwa ostatnie elementy pochodzą z danych konta, a klucze tylko z konfiguracji. Dlatego klucze traktuje się jak hasło: ich ujawnienie osłabia ochronę wszystkich sesji na stronie. Ten sam plik wp-config.php zawiera zwykle hasło do bazy danych, więc jego odczyt przez atakującego jest incydentem wymagającym wymiany obu sekretów.

Zmiana kluczy ma natychmiastowy skutek. Dokumentacja stwierdza, że można je zmienić w dowolnym momencie, by unieważnić wszystkie istniejące ciasteczka, a wszyscy użytkownicy muszą wtedy zalogować się ponownie ^[1]. Dotyczy to także atakującego, który przejął sesję administratora: jego skradzione ciasteczko przestaje pasować do nowego podpisu. Wymiana nie zmienia jednak haseł kont, więc sama nie wystarcza po włamaniu.

Dobre praktyki

• Unikalne klucze dla każdej instalacji i każdego środowiska; środowisko testowe nie powinno dzielić kluczy z produkcją.
• Wartości z generatora ^[1], nigdy ręcznie wymyślone ani skopiowane z poradnika.
• Klucze trzymane poza repozytorium kodu, jak inne sekrety w zarządzaniu sekretami.
• Wymiana kluczy po każdym podejrzeniu wycieku, co odpowiada zasadzie rotacji kluczy.
• Po włamaniu wymiana kluczy razem z hasłami. CERT Polska zaleca po przejęciu strony zmianę wszystkich haseł oraz kluczy, do których atakujący mógł uzyskać dostęp ^[6]. W WordPressie oznacza to nowe klucze i sole, nowe hasła kont i nowe hasło do bazy. Dalsze kroki opisuje hasło czyszczenie przejętej strony.

Sama wymiana kluczy nie usuwa tylnej furtki ani nieautoryzowanego konta administratora. Intruz z działającą furtką zaloguje się ponownie i dostanie ciasteczko podpisane nowymi kluczami.

Historia

Mechanizm nie powstał od razu w obecnej postaci. Według opisu z 2015 roku unikalne klucze i sole pojawiły się w WordPressie 2.5, a w wersji 2.7 zostały rozbudowane ^[7]. Ten sam opis dzieli pary na dwie grupy: sześć stałych chroni ciasteczka, a para NONCE_KEY i NONCE_SALT zabezpiecza dane przesyłane w adresach URL i formularzach ^[7]. Autor zaleca okresową regenerację kluczy, bo unieważnia ona sesje, które mogły zostać przejęte ^[7].

Starsze instalacje, zakładane przed pojawieniem się wszystkich ośmiu stałych, mogą mieć w pliku konfiguracyjnym tylko ich część. Brakujące wartości WordPress uzupełnia wtedy wpisami w bazie danych ^[2], więc przy przeglądzie konfiguracji warto sprawdzić, czy w wp-config.php jest komplet ośmiu definicji z generatora ^[1].