dane uwierzytelniające

Dane uwierzytelniające to informacje lub obiekty, którymi użytkownik albo program potwierdza swoją tożsamość: hasło, klucz, certyfikat, token. NIST definiuje poświadczenie (credential) jako obiekt lub strukturę danych, która w sposób wiarygodny wiąże tożsamość, przez identyfikator, z co najmniej jednym środkiem uwierzytelniania posiadanym i kontrolowanym przez użytkownika ^[1]. W praktyce dane uwierzytelniające są głównym łupem w większości ataków na konta. Kto je ma, ten dla systemu jest właścicielem konta.

Jak działa

Uwierzytelnianie polega na porównaniu tego, co przedstawia użytkownik, z tym, co zna system. Użytkownik podaje login i hasło, serwer liczy skrót hasła z zapisaną solą i porównuje go z zapisanym. Po udanym logowaniu serwer wydaje token sesyjny, zwykle w ciasteczku. Od tej chwili to token pełni funkcję danych uwierzytelniających do końca sesji.

System nie widzi człowieka, tylko dane. Dlatego MITRE ATT&CK opisuje technikę T1078 „Valid Accounts”: atakujący zdobywają i wykorzystują dane uwierzytelniające istniejących kont, by uzyskać początkowy dostęp, utrzymać się w systemie, podnieść uprawnienia albo ukryć działania ^[2]. Przejęte dane pozwalają ominąć kontrolę dostępu i łączyć się z usługami zdalnymi, takimi jak VPN czy pulpit zdalny ^[2].

Rodzaje

OWASP zalicza do sekretów wymagających zarządzania klucze API, dane logowania do baz, uprawnienia IAM, klucze SSH i certyfikaty ^[4]. MITRE rozróżnia w technice T1078 konta domyślne, domenowe, lokalne i chmurowe ^[2]. Coraz częściej hasło zastępuje passkey, czyli para kluczy kryptograficznych związana z urządzeniem.

W WordPressie

Na typowej stronie WordPress istnieje kilka rodzajów danych uwierzytelniających, każdy z innym zakresem władzy.

• Hasła kont w tabeli wp_users, zapisane jako skróty.
• Ciasteczka logowania, które po zalogowaniu zastępują hasło; ich kradzież daje dostęp do panelu bez znajomości hasła.
• Hasła aplikacji (application passwords) dostępne od wersji 5.6 do uwierzytelniania Basic w REST API przez HTTPS ^[7].
• Login i hasło bazy danych w wp-config.php, a także klucze API usług płatności, poczty i kopii zapasowych zapisywane przez wtyczki.
• Dane dostępowe spoza WordPressa: panel hostingu, SFTP, konto rejestratora domeny. Przejęcie któregokolwiek z nich daje władzę nad stroną.

Dokumentacja REST API podkreśla, że przy uwierzytelnianiu ciasteczkiem każde żądanie musi zawierać nonce z akcją wp_rest ^[7]. Chroni to przed tym, by samo ciasteczko wystarczyło do wykonania akcji z obcej strony.

Zagrożenia i skutki

Dane uwierzytelniające wyciekają na wiele sposobów.

• phishing: ofiara sama wpisuje hasło na fałszywej stronie logowania.
• infostealer: złośliwy program zbiera hasła zapisane w przeglądarce i ciasteczka sesji.
• Wycieki z innych serwisów i combolisty wykorzystywane w atakach credential stuffing.
• Słabe przechowywanie po stronie serwera: MITRE opisuje słabość CWE-522, gdy produkt przesyła lub przechowuje dane uwierzytelniające metodą podatną na przechwycenie albo odczyt ^[3]. Pokrewny błąd to hasło zaszyte w kodzie.

Skutkiem jest przejęcie konta. W przypadku konta administratora WordPressa oznacza to możliwość wgrania wtyczki z dowolnym kodem, a więc praktycznie przejęcie serwera w granicach uprawnień strony.

Przebieg typowej kradzieży przez fałszywą stronę logowania pokazuje schemat poniżej.

RYS. 1Kradzież danych uwierzytelniających przez fałszywą stronę

Jak się bronić

• Każde konto z innym, długim hasłem, najlepiej wygenerowanym przez menedżer haseł; zob. bezpieczne hasła.
• Uwierzytelnianie wieloskładnikowe (MFA) na kontach administratorów, hostingu i poczty. Kody jednorazowe można jednak wyłudzić, co pokazuje przykład niżej; odporniejsze są klucze FIDO2 i passkey.
• Sekrety aplikacji poza kodem źródłowym. OWASP wskazuje jako złą praktykę sekrety zapisane jawnie w kodzie i rozrzucone po plikach konfiguracyjnych ^[4]. Szerzej opisuje to zarządzanie sekretami.
• Regularna rotacja sekretów maszynowych, aby skradzione działały krótko ^[4]. Hasła użytkowników OWASP wyłącza z rutynowej rotacji: zmienia się je przy podejrzeniu lub dowodzie kompromitacji ^[4].
• Zasada najmniejszych uprawnień dla kont i kluczy, tak aby wyciek jednego sekretu nie otwierał wszystkiego ^[4].

Historia i przykłady

Komunikat zespołu wtyczek WordPress.org z 29 czerwca 2024 roku opisał wstrzyknięcie złośliwego kodu do kilku wtyczek w oficjalnym katalogu ^[6]. Atakujący nie wykorzystali błędu w WordPress.org, tylko hasła autorów wtyczek, które ci używali także w serwisach, z których wcześniej wyciekły dane ^[6]. WordPress.org zaczął wymuszać zmianę haseł wszystkich autorów wtyczek i zachęcił ich do włączenia uwierzytelniania dwuskładnikowego (2FA) ^[6].

CERT Polska 12 czerwca 2026 roku opisał kampanię grupy UNC1151 wymierzoną w użytkowników poczty Gmail ^[5]. Fałszywe strony logowania wyłudzały adres i hasło, a gdy ofiara podała dane uwierzytelniające, atakujący automatycznie próbowali zalogować się na jej konto i wyłudzić także kod drugiego składnika ^[5].