credential stuffing

Credential stuffing to zautomatyzowane logowanie do serwisu parami login–hasło pochodzącymi z wycieków z innych serwisów. MITRE opisuje tę technikę jako użycie danych logowania ze zrzutów po naruszeniach niezwiązanych kont, by dostać się do kont docelowych dzięki pokrywaniu się haseł ^[2]. Atak działa, bo ludzie powtarzają to samo hasło w kontach prywatnych i służbowych ^[2]. W odróżnieniu od zgadywania, atakujący nie szuka hasła; sprawdza, czy hasło znane z innego miejsca pasuje także tutaj.

Jak działa

Punktem wyjścia jest wyciek danych z dowolnego serwisu. Pary login–hasło z wielu wycieków łączy się w combolisty (combolist). Jeśli w wycieku były tylko skróty, poprzedza to łamanie haseł. Następnie program, często rozproszony na wiele adresów, próbuje logować się każdą parą w atakowanym serwisie. Przebieg pokazuje schemat poniżej.

RYS. 1Od wycieku do przejętego konta

OWASP wskazuje czynnik, który ułatwia ten atak: wiele stron używa adresu e-mail jako nazwy użytkownika, a większość osób ma jeden adres do wszystkich kont, więc para e-mail i hasło jest bardzo skuteczna w atakach credential stuffing ^[1].

Credential stuffing to jedna z czterech podtechnik ataku siłowego w klasyfikacji MITRE ^[2]. Różnica względem klasycznego ataku siłowego (brute-force) i password spraying polega na tym, co atakujący zmienia między próbami ^[1]. Porównanie odmian i dopasowanych do nich liczników prób zawiera artykuł o ochronie przed atakami brute force.

W WordPressie

Ostrzeżenie OWASP dotyczy każdej strony, na której użytkownicy logują się adresem e-mail. Każda strona z kontami klientów, na przykład sklep albo serwis członkowski, jest potencjalnym celem, a konto administratora celem najcenniejszym. Dokumentacja WordPressa zaleca silne, unikatowe hasła, menedżer haseł, uwierzytelnianie dwuskładnikowe (two-factor authentication, 2FA) dla administratorów, ograniczanie liczby prób logowania i przegląd nieudanych logowań w logach ^[8].

Ten sam mechanizm może uderzyć w cały ekosystem. Zespół katalogu wtyczek WordPress.org napisał 29 czerwca 2024 roku, że atakujący, wykorzystując hasła ujawnione w wyciekach z innych serwisów, dodali złośliwy kod do kilku wtyczek w katalogu ^[7]. Opis odpowiada definicji credential stuffing, a przejęte konto autora wtyczki stało się narzędziem ataku na łańcuch dostaw (supply chain attack); szczegóły incydentu i zmiany w WordPress.org opisuje tamten artykuł.

Zagrożenia i skutki

Bezpośrednim skutkiem jest przejęcie konta, a dalej to, na co konto pozwala: zakupy, wypłaty, zmiana danych kontaktowych albo publikacja treści. Serwis traci zaufanie użytkowników, choć jego własna baza mogła nigdy nie wyciec.

Sam atak ma skutki uboczne. MITRE zauważa, że credential stuffing może powodować liczne nieudane uwierzytelnienia i blokady kont, zależnie od polityki serwisu ^[2]. Duża liczba prób obciąża też serwer, podobnie jak inne złośliwe boty.

Trudność polega na tym, że pojedyncza próba wygląda jak zwykłe logowanie: poprawny login, czasem poprawne hasło. Atak nie musi przekraczać limitu prób na jednym koncie, bo każdą parę sprawdza się zwykle raz. Dlatego sam licznik na koncie, wymagany przez NIST na poziomie nie więcej niż 100 kolejnych nieudanych prób ^[3], nie wystarcza. Potrzebna jest analiza ruchu jako całości.

Jak się bronić

OWASP za najskuteczniejszą obronę uważa uwierzytelnianie wieloskładnikowe (multi-factor authentication, MFA) i przytacza analizę Microsoftu, według której MFA zatrzymałoby 99,9% przejęć kont ^[1]. Drugi składnik może być wymagany zawsze albo tylko przy podejrzanym logowaniu, na przykład z nowego urządzenia, z nietypowej lokalizacji albo przez znany serwer proxy ^[1]. Gdy MFA nie da się wprowadzić, OWASP proponuje utrudnienia strukturalne: nieprzewidywalne nazwy użytkowników zamiast adresów e-mail, logowanie w kilku krokach i wymóg wykonania JavaScriptu, który komplikuje pracę prostych narzędzi ^[1]. Może też celowo spowalniać podejrzane żądania albo podnosić ich koszt obliczeniowy ^[1]. Pozostałe warstwy zestawia tabela.

OWASP zastrzega, że blokowanie adresów IP może wystarczyć na mniej zaawansowane ataki, ale nie powinno być jedyną ani główną obroną ^[1]. Zaleca obronę warstwową i monitorowanie, czy warstwy działają ^[1]. Ważnym sygnałem jest logowanie z poprawnym hasłem, które nie przeszło weryfikacji drugiego składnika: OWASP zaleca wtedy powiadomić użytkownika, by zmienił hasło ^[1]. MITRE dodaje reset haseł kont, o których wiadomo, że zostały skompromitowane ^[2].

NIST wymaga, by nowe hasło było porównywane z listą haseł popularnych, przewidywalnych i ujawnionych, w tym z haseł z wycieków ^[3]. OWASP jako przykład takiego źródła podaje usługę Pwned Passwords ^[1]. Jej API działa w modelu k-anonimowości: przyjmuje tylko pierwszych 5 znaków skrótu SHA-1 hasła i nie wymaga klucza ^[6].

GET https://api.pwnedpasswords.com/range/5BAA6

Po stronie użytkownika podstawą są unikatowe hasła dla każdego serwisu. Takie hasło może wyciec razem z serwisem, ale nie otworzy żadnego innego konta.

Historia i przykłady

Niebezpiecznik 28 listopada 2022 roku opisał przejęcia kont w serwisie Lotto.pl. Według wpisu ktoś sięgnął do baz z wyciekami z różnych serwisów, wziął z nich loginy i hasła, a następnie sprawdził, czy te same dane pozwalają zalogować się na lotto.pl ^[4]. Po incydencie serwis wprowadził między innymi ograniczenie liczby prób logowania i szersze użycie CAPTCHA ^[4].

Ten sam serwis 8 lipca 2025 roku opisał przypadek klienta domu maklerskiego XTB, który stracił około 150 000 złotych po przejęciu konta ^[5]. Przyczyną było hasło użyte wcześniej w innym serwisie, które wyciekło, a na koncie nie było włączone uwierzytelnianie dwuskładnikowe ^[5]. W obu opisanych przypadkach hasła pochodziły z wycieków z innych serwisów, a nie z atakowanego.