limit prób logowania

Limit prób logowania to ochrona przed zgadywaniem haseł, która ogranicza liczbę i częstotliwość nieudanych prób uwierzytelnienia. OWASP określa blokadę konta jako najpowszechniejszą ochronę przed takimi atakami: po określonej liczbie nieudanych logowań kolejne próby są wstrzymywane na pewien czas ^[1]. Brak takiego ograniczenia MITRE opisuje jako słabość CWE-307, w której produkt nie stosuje wystarczających środków przeciw wielu nieudanym próbom w krótkim czasie ^[3]. Mechanizm należy do szerszej ochrony przed atakami brute force.

Jak działa

System prowadzi licznik nieudanych prób i porównuje go z progiem. OWASP wymienia trzy parametry, które trzeba ustalić: liczbę nieudanych prób przed blokadą (próg), okres, w którym te próby muszą wystąpić (okno obserwacji), oraz czas trwania blokady ^[1]. Licznik powinien być związany z kontem, a nie z adresem IP, bo inaczej atak rozproszony na wiele adresów go obejdzie ^[1].

RYS. 1Obsługa nieudanej próby logowania

Zamiast stałego czasu blokady można stosować blokadę wykładniczą. OWASP podaje przykład, w którym blokada zaczyna się od bardzo krótkiego okresu, na przykład jednej sekundy, i podwaja się po każdej kolejnej nieudanej próbie ^[1]. NIST w wytycznych SP 800-63B wymaga, by weryfikator ograniczał liczbę kolejnych nieudanych prób dla danego uwierzytelniacza na jednym koncie do nie więcej niż 100 ^[2]. Jako sposoby zmniejszenia ryzyka blokady NIST wymienia test wykrywający boty przed logowaniem, oczekiwanie rosnące wraz ze zbliżaniem się do limitu (na przykład od 30 sekund do godziny) oraz techniki adaptacyjne oparte na adresie IP, geolokalizacji, rytmie żądań czy metadanych przeglądarki ^[2].

Odmiany

Pod jedną nazwą kryje się kilka mechanizmów. MITRE jako środki zaradcze wymienia rozłączenie użytkownika po kilku nieudanych próbach, limit czasowy, blokadę atakowanego konta i wymóg wykonania zadania obliczeniowego ^[3].

OWASP traktuje CAPTCHA jako warstwę uzupełniającą, a nie samodzielną ochronę, i radzi wymagać jej dopiero po kilku nieudanych próbach, a nie od pierwszego logowania ^[1].

W WordPressie

Dokumentacja WordPressa zaleca ograniczanie tempa żądań do /wp-login.php i /xmlrpc.php na poziomie serwera WWW albo WAF ^[4]. Jeśli dostawca hostingu lub CDN nie ogranicza tempa na brzegu, dokumentacja wskazuje, że logowania może spowalniać wtyczka bezpieczeństwa ^[4]. Zaznacza przy tym, że wtyczki działają w PHP i pod silnym atakiem same zużywają zasoby, więc lepsze jest ograniczanie na brzegu albo na serwerze ^[4].

Osobnym celem jest XML-RPC. Według dokumentacji xmlrpc.php jest częstym celem ataków siłowych, zwłaszcza przez metodę system.multicall ^[4]. Limit ustawiony tylko na formularzu wp-login.php nie obejmuje więc tej drogi. Dokumentacja radzi też przeglądać logi nieudanych logowań i czasowo blokować nadużywające adresy, na przykład narzędziem fail2ban ^[4].

Przykładowa reguła ograniczająca tempo w serwerze nginx (ilustracja, wartości dobiera się do ruchu):

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
}

Limit prób warto łączyć z innymi warstwami, które wymienia ta sama dokumentacja: rezygnacją z loginu admin, silnymi hasłami z menedżera haseł i uwierzytelnianiem dwuskładnikowym (2FA) dla administratorów ^[4]. Rdzeń WordPressa nie ma wbudowanego 2FA; trzeba je dodać wtyczką albo przez zewnętrznego dostawcę tożsamości ^[4].

Zagrożenia i skutki

Bez limitu atakujący może wykonać dowolną liczbę prób z różnymi hasłami i w końcu uzyskać dostęp do konta w ataku siłowym (brute-force) ^[3]. Skutkiem jest przejęcie konta, a przy koncie administratora cała witryna.

Źle zaprojektowany limit tworzy nowe ryzyko. Niebezpiecznik ostrzega, że blokowanie dostępu do konta po kilku nieudanych próbach pozwala komuś, kto zna login ofiary, celowo i wielokrotnie wywoływać blokadę, czyli przeprowadzić atak odmowy usługi (DoS) na konkretnego użytkownika ^[5]. OWASP również wymaga, by mechanizmu nie dało się użyć do blokowania kont innych osób ^[1].

Blokada pojedynczego konta nie chroni też przed password spraying. W opisanym przez Niebezpiecznika scenariuszu atakujący sprawdza jedno popularne hasło kolejno na wielu kontach, więc żadne konto nie osiąga progu ^[5]. Przeciw temu pomagają techniki adaptacyjne, które oceniają adres, rytm żądań i metadane przeglądarki ^[2], a przeciw credential stuffing dodatkowo drugi składnik logowania.

Dobre praktyki

• Licznik per konto, nie tylko per adres. OWASP wiąże licznik z kontem, żeby atak z wielu adresów go nie obszedł ^[1]; ograniczenia per adres IP można dodać jako osobną warstwę na serwerze ^[4].
• Opóźnienie zamiast trwałej blokady. Niebezpiecznik zaleca, by nie blokować konta na stałe po nieudanych próbach, tylko po kilku porażkach żądać rozwiązania CAPTCHA ^[5]. NIST dopuszcza rosnący czas oczekiwania jako sposób ograniczenia blokad ^[2].
• Alternatywna droga dla właściciela konta. OWASP wskazuje, że w czasie blokady prawowity użytkownik powinien mieć sposób odzyskania dostępu, na przykład przez odzyskiwanie hasła ^[1].
• Wszystkie wejścia. Limit obejmuje formularz, XML-RPC i API, a nie tylko stronę logowania ^{[4] [5]}.
• Obserwacja. Logi nieudanych logowań pokazują, skąd przychodzi atak i czy limit działa ^[4].

Historia i przykłady

Brak limitu prób wciąż pojawia się w komunikatach o podatnościach. CERT Polska 30 czerwca 2026 roku opublikował informację o podatnościach w systemie e-BOK firmy KTM System; według komunikatu system nie ograniczał liczby prób logowania ani nie limitował ich czasowo, co pozwalało wykonywać nieograniczoną liczbę żądań uwierzytelnienia ^[6]. Ta sama publikacja opisuje błędy utrwalenia sesji, CSRF i słabych wymagań dotyczących haseł; poprawkę zawiera wydanie z czerwca 2026 roku ^[6].