bezpieczne hasła

Bezpieczne hasła to zestaw nawyków chroniących konta: długie i unikalne hasło do każdej usługi, przechowywane w menedżerze haseł i zmieniane nie okresowo, lecz dopiero po podejrzeniu ujawnienia. CERT Polska zalicza je do cyberhigieny: nie podając nikomu swoich danych uwierzytelniających i ustawiając mocne, unikalne hasła, użytkownik dba o swoje bezpieczeństwo w sieci ^[1]. Współczesne zalecenia, zarówno polskie, jak i amerykańskiego NIST, odeszły od wymuszania znaków specjalnych i okresowej zmiany na rzecz długości i unikalności ^{[1] [2]}.

Zasady

Najważniejsze reguły wynikają z tego, jak hasła są łamane. Krótkie hasło padnie w ataku siłowym (brute force), hasło słownikowe w ataku ze słownikiem, a hasło użyte w kilku serwisach w credential stuffing po pierwszym wycieku danych.

• Długość. CERT Polska zaleca co najmniej 14 znaków ^[1]. NIST wymaga co najmniej 15 znaków od hasła, które jest jedynym składnikiem logowania, i co najmniej 8 znaków, gdy hasło jest częścią logowania wieloskładnikowego ^[2]. Weryfikator powinien przyjmować hasła o długości co najmniej 64 znaków ^[2].
• Fraza zamiast słowa. CERT Polska rekomenduje kombinację kilku słów i podaje przykład w rodzaju NaKolacjeZjemZielonePomidory ^[1]. Taka fraza jest długa, a jednocześnie łatwa do zapamiętania; przykładu z poradnika nie należy oczywiście używać jako własnego hasła.
• Unikalność. Różne hasła do różnych usług, zwłaszcza do poczty, banku i mediów społecznościowych ^[1].
• Menedżer haseł. CERT Polska rekomenduje menedżery haseł, także te wbudowane w przeglądarki i telefony ^[1]. NIST wymaga, by weryfikator pozwalał na menedżery i autouzupełnianie, i zaleca dopuszczenie wklejania hasła ^[2].
• Zmiana tylko po ujawnieniu. Hasło zmienia się wtedy, gdy jest podejrzenie, że ktoś je poznał ^[1].
• Drugi składnik. CERT Polska zaleca włączenie weryfikacji dwuetapowej: kodu jednorazowego, potwierdzenia w aplikacji albo klucza USB ^[1]; zob. uwierzytelnianie dwuskładnikowe.

Obieg hasła zgodny z tymi zasadami pokazuje schemat poniżej.

RYS. 1Cykl życia hasła

Stare i nowe zalecenia

Część dawnych reguł nadal krąży w regulaminach firm i formularzach rejestracji. NIST SP 800-63B-4 wprost je wycofuje.

Lista zakazanych haseł ma według NIST obejmować hasła z wcześniejszych wycieków, słowa słownikowe i słowa związane z kontekstem usługi ^[2]; takie zbiory krążą jako combolisty (combo lists).

W WordPressie

Dokumentacja utwardzania WordPressa odradza hasła będące przekształceniem własnego imienia, nazwy użytkownika, firmy lub witryny, słowa ze słownika w dowolnym języku, hasła krótkie oraz złożone tylko z cyfr albo tylko z liter ^[3]. Zaleca też logowanie dwuetapowe ^[3].

Na ekranie profilu przycisk generowania hasła (Generate Password) tworzy nowe hasło; użycie własnego słabego hasła wymaga zaznaczenia potwierdzenia ^[4]. Wskaźnik siły ocenia hasło od bardzo słabego do silnego, a przycisk wylogowania z innych miejsc (Log Out Everywhere Else) kończy sesje na innych urządzeniach ^[4]. Podpowiedź na tym ekranie wspomina o minimum siedmiu znakach i mieszaniu rodzajów znaków ^[4], co jest słabsze od zaleceń CERT Polska i NIST.

Po stronie serwera liczy się sposób przechowywania. Od wersji 6.8 WordPress zapisuje hasła użytkowników jako skróty bcrypt zamiast phpass, co znacząco podnosi koszt łamania haseł ze skradzionej bazy ^[5]. Istniejące hasła są przeliczane przy najbliższym logowaniu lub zmianie hasła ^[5]. Ponieważ bcrypt ma ograniczenie długości danych wejściowych, WordPress najpierw skraca hasło funkcją SHA-384, dzięki czemu obsługuje także dłuższe frazy; takie skróty mają prefiks $wp$2y$ ^[5]. Hasła aplikacji i klucze resetu hasła są od tej wersji skracane algorytmem BLAKE2b ^[5]. O mechanizmie mówią hasła funkcja skrótu (hashowanie) i sól.

Podgląd algorytmu zapisanego hasła daje funkcja PHP, bez ujawniania samego hasła.

// informacja diagnostyczna: jakim algorytmem zapisano skrót hasła użytkownika
$user = get_user_by( 'login', 'redakcja' );
var_dump( password_get_info( $user->user_pass )['algoName'] );

Zagrożenia i skutki

Słabe lub powtarzane hasło jest najprostszą drogą do przejęcia konta. W czerwcu 2024 roku zespół katalogu wtyczek WordPress.org wymusił reset haseł wszystkich autorów wtyczek po tym, jak atakujący, używając haseł z wycieków w innych serwisach, dodali złośliwy kod do kilku wtyczek ^[6]. Zespół podkreślił, że przyczyną nie była luka w WordPress.org, lecz powtarzanie haseł ^[6]. Przejęte konto autora to gotowy atak na łańcuch dostaw, bo złośliwa aktualizacja trafia do wszystkich instalacji wtyczki.

Dobre praktyki

• Używać menedżera haseł i generować w nim hasła do każdej usługi osobno ^[1].
• Włączyć drugi składnik logowania, przede wszystkim na kontach administratorów ^[3]; tam, gdzie to możliwe, rozważyć passkey.
• Na stronach WordPress ograniczyć liczbę prób logowania; zob. limit prób logowania.
• Nie zostawiać haseł w kodzie ani w plikach konfiguracyjnych repozytorium; zob. zaszyte w kodzie hasło.
• Po wycieku zmienić hasło w danym serwisie i wszędzie tam, gdzie było użyte ponownie, a także dane dostępu do SFTP, panelu hostingu i bazy ^{[6] [3]}.
• Zmienić każde domyślne hasło przed udostępnieniem usługi w sieci.

Zasady te nie usuwają ryzyka phishingu: nawet najlepsze hasło wpisane na fałszywej stronie trafia do przestępcy. Dlatego hasło jest tylko jedną z warstw ochrony konta, obok drugiego składnika logowania.