Bezpieczne formularze logowania i rejestracji klientów: ochrona przed enumeracją użytkowników, throttling prób logowania oraz właściwe komunikaty o błędach

Problem: logowanie i rejestracja zdradzają więcej, niż powinny

Typowy scenariusz: w panelu hostingu albo w logach WordPressa zaczyna pojawiać się fala nieudanych logowań. Klienci zgłaszają maile z resetem hasła, których nie zamawiali. Część z nich widzi komunikaty w stylu „Użytkownik o takim adresie e‑mail nie istnieje” i zastanawia się, czy na pewno dobrze założyli konto. Ty z kolei nie chcesz dokręcać śruby bezpieczeństwa, żeby nie zniechęcić klientów – więc finalnie nie robisz prawie nic.

Efekt: formularz logowania i rejestracji staje się dla atakującego wygodnym interfejsem API. Pozwala potwierdzać, czy dany e‑mail istnieje w bazie, testować setki haseł na sekundę, a przy okazji obciąża serwer. Przy odrobinie pecha kilka kont rzeczywiście zostaje przejętych – wystarczy, że część użytkowników używa tego samego hasła w kilku serwisach.

Bezpieczny formularz logowania/rejestracji z punktu widzenia enumeracji użytkowników i prób logowania musi rozwiązać trzy rzeczy naraz:

• nie zdradzać, czy dane konto istnieje (enumeracja użytkowników),
• ograniczać tempo prób logowania (throttling logowania),
• zachować sensowne, zrozumiałe komunikaty błędów dla uczciwych klientów.

Do tego dochodzi jeszcze pytanie: jak bardzo można zaostrzyć zabezpieczenia, żeby nie rozwalić UX? Inne podejście będzie rozsądne w małym sklepie z kilkudziesięcioma klientami dziennie, a inne w serwisie z danymi medycznymi czy finansowymi.

Skąd biorą się wycieki informacji: mechanika enumeracji i sygnały dla atakującego

Gdzie formularz niechcący „podpowiada”, że konto istnieje

Enumeracja użytkowników to sytuacja, w której napastnik jest w stanie potwierdzić, że konkretny login lub e‑mail istnieje w systemie – bez dostępu do panelu admina, tylko przez obserwację zachowania aplikacji. Z punktu widzenia atakującego wystarczą drobne różnice:

• inna treść komunikatu błędu,
• inny czas odpowiedzi,
• inna reakcja na reset hasła czy rejestrację.

Różne komunikaty błędów przy logowaniu

Najczęstszy przypadek:

• dla nieistniejącego konta: „Nie ma użytkownika o takim adresie e‑mail”,
• dla istniejącego konta, ale złego hasła: „Hasło jest nieprawidłowe”.

Taki układ pozwala botowi w prosty sposób zbudować listę poprawnych loginów: jeśli komunikat brzmi „hasło błędne”, konto istnieje, jeśli „użytkownik nie istnieje” – nie ma go w bazie. Przy odrobinie automatyzacji można w ten sposób „przetestować” tysiące e‑maili z wycieków.

Czas odpowiedzi jako podpowiedź

Nawet jeśli treść komunikatu jest identyczna, aplikacja często inaczej przetwarza różne przypadki:

• dla nieistniejącego loginu – natychmiast zwraca odpowiedź (brak sprawdzania hasła),
• dla istniejącego – wykonuje dodatkowe operacje (np. porównywanie hasha hasła), co trwa trochę dłużej.

Bot może zmierzyć czas odpowiedzi z dokładnością do milisekund. Jeśli różnica między „login istnieje” a „login nie istnieje” jest powtarzalna, enumeracja dalej jest możliwa – nawet przy neutralnym komunikacie. W praktyce wystarczy:

• dodać minimalne, stałe opóźnienie dla wszystkich błędów,
• upewnić się, że logika po stronie serwera wykonuje podobny zestaw operacji dla obu przypadków.

Reset hasła i rejestracja jako kanał enumeracji

Enumeracja dzieje się bardzo często nie tyle na samym logowaniu, co w:

• formularzu resetu hasła – komunikat „wysłano e‑mail z resetem” tylko wtedy, gdy konto istnieje,
• formularzu rejestracji – komunikat „konto z takim e‑mailem już istnieje, zaloguj się” dla istniejącego adresu.

Scenariusz ataku jest prosty:

1. Atakujący ma listę tysięcy e‑maili (np. z poprzednich wycieków).
2. Automatycznie wysyła je do formularza „zapomniałem hasła”.
3. Dla tych, gdzie dostaje komunikat „wysłano e‑mail”, wie, że konto istnieje.
4. Tę listę wykorzystuje później do ataków typu credential stuffing (testuje hasła z innych wycieków).

Podobnie z rejestracją: komunikat „konto z takim e‑mailem już istnieje” jest dla napastnika złotą informacją, jeśli można go odpytywać bez żadnych limitów.

Masowe próby logowania bez throttlingu

Credential stuffing i słabe hasła

Większość użytkowników powtarza hasła w kilku miejscach. Atakujący korzysta z tego, używając list loginów i haseł wyciekłych z innych serwisów. Jeśli aplikacja nie ma sensownego throttlingu:

• można przetestować setki lub tysiące par login/hasło na minutę,
• kilka kont prawie na pewno zadziała,
• po drodze serwer zacznie wolniej działać także dla uczciwych klientów.

Brak limitów na IP, konto, sieć

Bez żadnych limitów aplikacja zachowuje się tak samo przy 10 próbach logowania i przy 10 000. Typowe skutki:

• wzrost obciążenia CPU i bazy danych,
• potencjalne przekroczenie limitów hostingu lub SaaS,
• przejęte konta użytkowników z powtarzanymi hasłami.

Warto zwrócić uwagę, że „captcha przy logowaniu” bez throttlingu nie rozwiązuje problemu. Dobre boty mogą ją obejść (np. przez usługi rozpoznawania CAPTCHA), a użytkowników bardziej frustruje ciągłe „klikaj w obrazki” niż jednorazowe opóźnienie lub krótka blokada.

Neutralne komunikaty błędów: jak mówić użytkownikowi prawdę, ale nie atakującemu

Zasada: tyle informacji, ile trzeba – bez różnicowania po istnieniu konta

Podstawowe założenie: treść komunikatu, który widzi użytkownik, nie może zależeć od tego, czy dane konto istnieje. Inaczej mówiąc: front nie powinien „zdradzać” różnicy między „zły login”, „złe hasło” i „konto nie istnieje”.

Przykłady niebezpiecznych komunikatów

Przy logowaniu:

• „Nie ma użytkownika o takim adresie e‑mail.” – ujawnia brak konta.
• „Hasło jest błędne.” – ujawnia istnienie konta, skoro przechodzimy do sprawdzania hasła.
• „Ten użytkownik jest zablokowany.” – często pokazywane bez podania poprawnego hasła.

Przy resecie hasła:

• „Na podany adres wysłano instrukcję resetu hasła.” – tylko dla istniejących kont.
• „Nie znaleziono konta o podanym adresie e‑mail.” – potwierdza brak konta.

Przy rejestracji:

• „Konto z takim e‑mailem już istnieje, zaloguj się.” – dobra podpowiedź dla użytkownika, ale świetna dla atakującego, jeśli można ją wywoływać masowo.

Bezpieczniejsze wersje komunikatów

Neutralne podejście zakłada komunikaty, które nie wskazują, czy dany e‑mail/login znajduje się w bazie. Przykłady:

• Logowanie: „Nieprawidłowy login lub hasło.” – zawsze ten sam tekst, niezależnie od przyczyny błędu.
• Reset hasła: „Jeśli konto z takim adresem istnieje, wysłaliśmy instrukcję resetu hasła.” – brak potwierdzenia, że konto istnieje.
• Rejestracja: „Jeśli korzystasz już z tego adresu w serwisie, użyj opcji odzyskiwania hasła.” – bez wprost podanej informacji, że konto już jest.

W kodzie aplikacji i logach możesz oczywiście rozróżniać te sytuacje – ważne, żeby warstwa prezentacji nie podpowiadała ich atakującemu.

Jak nie zniechęcić uczciwego użytkownika

Podpowiedzi w interfejsie zamiast zdradzających komunikatów

Brak szczegółowych komunikatów nie musi oznaczać, że użytkownik zostaje sam z lakonicznym błędem. Kilka prostych trików UX pomaga, nie osłabiając bezpieczeństwa:

• Dodaj pod polem e‑mail krótką wskazówkę: „Użyj adresu, którego użyłeś przy zakładaniu konta”.
• Pod przyciskiem logowania umieść zawsze widoczny link „Nie pamiętasz hasła?” – niech będzie to domyślna ścieżka, zamiast specjalnego komunikatu „konto istnieje, użyj resetu”.
• Przy rejestracji dodaj neutralny tekst pod formularzem: „Jeśli już masz konto, zaloguj się lub skorzystaj z przypomnienia hasła”.

Kluczem jest to, aby nie zmieniać treści komunikatów w zależności od tego, co aplikacja wie o danym e‑mailu. Użytkownik ma zrozumieć, co może zrobić dalej (spróbować innego loginu, zresetować hasło), ale bez potwierdzania „ten e‑mail na pewno jest w bazie”.

Obsługa blokad i throttlingu po ludzku

Throttling logowania wprowadza dodatkową kategorię błędów: blokady czasowe i opóźnienia. Dobrze, gdy komunikaty dla użytkownika:

• jasno mówią, co się stało,
• podają przybliżony czas, kiedy można spróbować ponownie,
• proponują alternatywne działanie (np. reset hasła).

Przykładowe komunikaty:

• „Z powodu wielu nieudanych prób logowania dostęp został tymczasowo ograniczony. Spróbuj ponownie za kilka minut lub skorzystaj z opcji resetu hasła.”
• „Ze względów bezpieczeństwa Twoje konto zostało chwilowo zablokowane. Sprawdź skrzynkę e‑mail – wysłaliśmy instrukcję odblokowania.” (dla serwisów bardziej wrażliwych).

Na froncie komunikat jest ogólny, ale w logach zapisujesz szczegóły: IP, login, liczbę prób, czas blokady. Dzięki temu możesz analizować ataki i poprawiać ustawienia, nie zdradzając nic klientowi.

Throttling prób logowania: metody, progi i przykłady ustawień

Główne sposoby ograniczania prób logowania

Miękki throttling: opóźnienia

Najmniej inwazyjne, a bardzo skuteczne w małych i średnich serwisach są opóźnienia po nieudanych próbach logowania. Zasada:

• pierwsze 2–3 błędne próby – brak opóźnień,
• kolejne – dodawane 1–3 sekundy zwłoki przed odpowiedzią serwera,
• im więcej błędnych prób z rzędu, tym większa zwłoka (np. do 10–15 sekund maksymalnie).

Dla uczciwego użytkownika, który raz czy dwa razy pomylił hasło, różnica będzie prawie niezauważalna. Dla bota, który planuje wykonać tysiące prób, dodatkowe sekundy po każdej błędnej próbie dramatycznie zwiększają czas ataku.

Limity per IP i per konto

Druga warstwa to twarde limity w określonym oknie czasowym:

• limit prób logowania z jednego adresu IP,
• osobny limit nieudanych prób dla jednego konta (login/e‑mail),
• czasowa blokada po przekroczeniu progu (np. 10–15 minut).

Podstawowa konfiguracja dla wielu małych/średnich serwisów może wyglądać tak:

• 5 nieudanych prób z jednego IP w ciągu 5 minut → lekkie opóźnienie (1–3 s),
• 10 nieudanych prób z jednego IP w ciągu 15 minut → blokada IP na 15 minut,
• 10 nieudanych prób dla jednego loginu/e‑maila w ciągu 10 minut → blokada konta na 10–15 minut + powiadomienie mailowe do właściciela.

Odpowiednie progi zależą od skali serwisu i charakteru użytkowników. Dla aplikacji wewnętrznych można sobie pozwolić na ostrzejsze ustawienia, dla sklepu B2C – raczej łagodniejsze.

Blokady per sieć / kraj i ochrona wyższego poziomu

W serwisach regularnie atakowanych pojawia się sens blokowania:

• całych zakresów IP (np. /24),
• konkretnych krajów lub regionów, z których na pewno nie korzystają klienci,
• ruchu z nietypowych user agentów (automaty, skrypty).

To już jednak „cięższa artyleria”, zwykle realizowana na poziomie firewalla, WAF (Web Application Firewall) lub usługi typu Cloudflare, a nie samej logiki aplikacji. Dla małych stron często wystarczą opóźnienia i proste limity.

Kiedy dokręcać śrubę: scenariusze dla różnych skal serwisu

Mały sklep lub strona usługowa

Założenia:

• kilka–kilkanaście logowań dziennie,
• główne ryzyko: przejęcie pojedynczych kont, zalew robotami, spowolnienie strony.

Przy takiej skali zwykle wystarczy prosty zestaw zabezpieczeń, które nie utrudnią życia klientom:

• ograniczenie do ok. 5–7 nieudanych prób z jednego IP w krótkim oknie (5–10 minut),
• delikatne opóźnienia po kilku błędach (1–2 sekundy),
• czasowa blokada konta po przekroczeniu progu błędów (np. 10 minut) + e‑mail z informacją o podejrzanej aktywności.

Na starcie można to zaimplementować na poziomie aplikacji (np. licznik prób w cache, Redisie lub bazie danych) i prostych reguł serwera www. Jeżeli pojawią się pierwsze realne ataki (nagłe skoki liczby błędnych logowań z jednego IP lub kraju), wtedy dopiero włączać dodatkowe warstwy: reguły w firewallu, reCAPTCHA przy podejrzanym ruchu czy integrację z WAF‑em dostawcy hostingu.

Dobrze działa zasada: nie komplikować panelu logowania ponad realne potrzeby. Jeżeli w małym sklepie za często blokujesz prawdziwych klientów, progi są zbyt agresywne. Lepiej podnieść limity i wzmocnić inne elementy, np. wymagania co do siły hasła, 2FA dla adresów administracyjnych czy wymuszanie potwierdzenia e‑maila.

Większy serwis SaaS lub bankowość internetowa

Przy setkach lub tysiącach logowań dziennie i wyższej wrażliwości danych ograniczenie do prostych opóźnień i blokad IP to za mało. Potrzebne są warstwy, które uwzględniają różne perspektywy:

• osobne limity na IP, konto, podsieć i kraj,
• adaptacyjne progi – np. łagodniejsze dla stałych klientów, ostrzejsze dla „nowych” adresów IP i urządzeń,
• dodatkowe uwierzytelnianie (2FA, SMS, aplikacja) wymuszane po przekroczeniu pewnego poziomu ryzyka, a nie tylko po logowaniu z nowej lokalizacji.

W praktyce oznacza to często połączenie kilku narzędzi: WAF do filtracji ruchu masowego, systemu SIEM/SOC do analizy wzorców ataków oraz logiki w samej aplikacji (liczniki prób, blokady per konto, reguły ryzyka). Kluczowe jest monitorowanie: suche progi w konfiguracji bez stałego przeglądu logów kończą się tym, że restrykcje żyją własnym życiem, a użytkownicy omijają zabezpieczenia przez support.

Im wyższa stawka (pieniądze, dane medyczne, dostęp do krytycznych systemów), tym bardziej opłaca się inwestować w detekcję anomalii zamiast statycznych limitów. Czasem lepiej dopuścić o jedno logowanie za dużo i złapać wzorzec ataku, niż prewencyjnie zablokować pół kraju i zasypać helpdesk skargami.

Bezpieczny formularz logowania i rejestracji to suma kilku prostych decyzji: neutralne komunikaty, spójna polityka throttlingu, przemyślane blokady i rozsądne wymagania wobec użytkownika. Jeśli już na etapie projektu zadasz pytanie „czy ten element pomaga użytkownikowi, nie ułatwiając pracy atakującemu?”, większość trudnych dylematów rozwiąże się sama – a pozostałe da się ogarnąć testami i regularnym przeglądem logów.

Testowanie formularzy logowania i rejestracji pod kątem enumeracji i throttlingu

Prosty „pentest” do zrobienia samodzielnie

Zanim wdrożysz nowe pluginy czy rozbudowane WAF‑y, dobrze zobaczyć, jak aktualne formularze zachowują się w praktyce. Da się to sprawdzić w kilkanaście minut:

• weź jeden istniejący adres e‑mail z bazy i jeden wymyślony, który na pewno nie jest zarejestrowany,
• przetestuj oba w tych samych scenariuszach: logowanie, reset hasła, rejestracja, formularz „przypomnienie loginu” (jeśli masz),
• obserwuj komunikaty błędów, kody HTTP i czasy odpowiedzi.

Jeżeli dla istniejącego e‑maila dostajesz komunikat innej treści niż dla nieistniejącego (albo odpowiedź przychodzi wyraźnie szybciej), masz podatność na enumerację. To samo dotyczy rejestracji: różne teksty typu „konto już istnieje, zaloguj się” vs „dziękujemy za rejestrację” po prostu klasyfikują e‑maile jako „w bazie / nie w bazie”.

Na co patrzeć przy testach – mini‑checklista

Żeby niczego nie pominąć, przy każdym formularzu przejdź przez krótką listę kontrolną:

• Treść komunikatów – czy dla różnych stanów (konto istnieje/nie istnieje, hasło złe/dobre) klient widzi znacząco inne teksty?
• Czas odpowiedzi – czy przy istniejącym e‑mailu odpowiedź jest zauważalnie szybsza lub wolniejsza (np. przez wysyłanie maila synchronicznie)?
• Kody odpowiedzi HTTP – czy dla błędnego loginu masz np. 401, a dla nieistniejącego użytkownika 404? To też jest wyciek informacji.
• Logika throttlingu – czy po serii błędów faktycznie pojawiają się opóźnienia lub blokada, a nie tylko suchy komunikat „błąd logowania”?
• Reset hasła – czy po podaniu nieistniejącego e‑maila komunikat nadal brzmi neutralnie („jeśli adres jest w naszej bazie…”)?
• Rejestracja – czy mechanizm sprawdzania „czy konto istnieje” nie podpowiada tego półgębkiem, np. w AJAX‑owych podpowiedziach w trakcie wpisywania?

Jeżeli na którymkolwiek z tych etapów możesz „na oko” odróżnić istniejącego użytkownika od nieistniejącego, tak samo zrobi to prosty skrypt atakującego.

Narzędzia, które pomagają obejrzeć problem oczami atakującego

Do testów nie trzeba od razu pełnego pakietu pentesterskiego, ale kilka narzędzi bardzo ułatwia pracę:

• DevTools w przeglądarce – zakładki Network i Timing pokażą różnice czasów odpowiedzi oraz Status code.
• curl / HTTPie – do szybkiego wysyłania serii żądań z różnymi danymi logowania i podglądu „surowych” odpowiedzi.
• Proste skrypty (Python, Node) – do symulacji kilkudziesięciu lub kilkuset prób logowania z jednego IP i sprawdzenia, kiedy odzywa się throttling.

Krótki test: odpal skrypt, który wykona np. 30 błędnych logowań pod rząd na to samo konto z tego samego IP. Jeśli po 30 żądaniach nadal dostajesz odpowiedź w takim samym czasie i bez dodatkowych komunikatów, throttling praktycznie nie działa.

CAPTCHA, 2FA i inne „dodatki”: kiedy pomagają, a kiedy tylko psują UX

CAPTCHA jako ostatnia linia obrony, nie pierwszy pomysł

Naturalny odruch przy widocznych atakach to: „dołóżmy CAPTCHA do logowania”. W wielu przypadkach to zbyt ciężkie rozwiązanie, które przede wszystkim obniża konwersję i irytuje klientów, a atakującym daje tylko chwilowe utrudnienie.

CAPTCHA ma sens w kilku scenariuszach:

• po przekroczeniu rozsądnej liczby nieudanych prób z jednego IP lub na jedno konto,
• przy podejrzanym ruchu (np. masowe próby z jednego kraju, którego normalnie nie obsługujesz),
• w połączeniu z innymi warstwami (limity, opóźnienia, analiza zachowania), a nie zamiast nich.

Nie ma sensu:

• pokazywać CAPTCHA od razu przy pierwszym błędzie logowania,
• wymuszać jej przy każdej rejestracji, jeśli prawdziwych spamowych kont jest kilka miesięcznie,
• opierać całego bezpieczeństwa logowania wyłącznie na tym, że „robot nie przejdzie obrazka”.

W małym sklepie częściej lepiej zadziałają miękkie opóźnienia + limity IP niż CAPTCHA na starcie logowania. CAPTCHA zostaw jako „plan B” na moment, gdy logi pokażą wyraźny wzrost zautomatyzowanych ataków.

Kiedy wymuszać 2FA, a kiedy tylko je proponować

Dwuskładnikowe uwierzytelnianie (2FA) bardzo podnosi bezpieczeństwo, ale też zwiększa tarcie przy logowaniu. W niektórych projektach to nieuniknione (bankowość, panel administracyjny), w innych lepiej podejść do tematu delikatniej.

W praktyce można rozróżnić trzy poziomy:

1. 2FA obowiązkowe – dla kont administracyjnych, paneli zarządzania sklepem, dostępu do danych szczególnie wrażliwych. Tu priorytetem jest bezpieczeństwo, nie wygoda.
2. 2FA silnie rekomendowane – dla klientów B2B, użytkowników przechowujących większe środki lub dane firmowe. Można zachęcać banerami, zniżkami na usługi czy dodatkowymi funkcjami dla kont zabezpieczonych 2FA.
3. 2FA opcjonalne – dla zwykłych klientów małego sklepu, gdzie przeważa wygoda i niski próg wejścia. Tam lepiej nie blokować rejestracji wymaganiem instalacji aplikacji 2FA.

W kontekście enumeracji 2FA nie rozwiązuje problemu, ale mocno ogranicza skutki przejęcia hasła. Dla małych serwisów rozsądnym kompromisem jest: 2FA wymagane dla panelu admina, dobrowolne dla klientów – plus dobrze skonfigurowany throttling i neutralne komunikaty.

Typowe błędy przy „uszczelnianiu” logowania i jak ich uniknąć

Zbyt szczegółowe komunikaty i „pomocne” podpowiedzi

Najczęstszy błąd przy poprawianiu UX to komunikaty pokroju:

• „Taki e‑mail nie istnieje w naszym systemie, zarejestruj się.”
• „Hasło jest błędne, ale e‑mail poprawny.”
• „Konto o tym adresie zostało usunięte.”

Z punktu widzenia klienta brzmią przyjaźnie. Z punktu widzenia atakującego to idealne API do budowania listy aktywnych kont. Rozwiązanie nie polega na „ogłupianiu” użytkownika, tylko na odpowiednim prowadzeniu go procesem:

• neutralny komunikat na błędzie,
• linki do resetu hasła i rejestracji,
• krótkie, jasne wyjaśnienie w help center (np. osobna strona), że system nie ujawnia, czy konto istnieje.

Jeśli support często dostaje pytania „czy mój e‑mail jest u was w bazie?”, zamiast odsłaniać tę informację w komunikatach, przygotuj gotową odpowiedź i proces weryfikacji po dodatkowych danych (np. numer zamówienia, NIP, telefon).

Agresywne blokady kont bez sensownej ścieżki odblokowania

Drugi biegun błędów to zbyt ostre limity, które częściej atakują zwykłych klientów niż prawdziwych napastników. Typowy scenariusz:

• 3 błędne logowania z rzędu → konto zablokowane do kontaktu z supportem,
• brak automatycznego odblokowania ani linku w mailu,
• support działa w godzinach biurowych, więc klient „odcięty” jest cały wieczór lub weekend.

Atakujący łatwo to wykorzysta do nękania klientów – masowo blokując konta, np. podanie błędnego hasła na znany e‑mail. Bez sensownej ścieżki odblokowania (link w mailu, SMS, automatyczne zdjęcie blokady po czasie) to idealny wektor ataku DoS na użytkowników.

Bezpieczniejszy schemat:

• blokada czasowa (10–30 minut) po serii nieudanych prób,
• mail do właściciela z informacją o podejrzanej aktywności + link „to nie byłem ja / zmień hasło”,
• opcjonalnie możliwość natychmiastowego odblokowania po pozytywnej weryfikacji 2FA.

W bardziej wrażliwych systemach konto po zbyt wielu seriach błędów może wymagać ręcznego odblokowania przez support, ale to już raczej domena bankowości i systemów krytycznych, a nie sklepów czy prostych portali.

Brak spójności między logowaniem, rejestracją a resetem hasła

Nawet jeśli sam formularz logowania jest neutralny, często „dziury” pojawiają się naokoło:

• reset hasła jasno mówi, czy e‑mail istnieje,
• rejestracja odrzuca e‑mail z komunikatem „konto już istnieje, zaloguj się”,
• formularz „zapomniałem loginu” zwraca konkretną nazwę użytkownika dla danego e‑maila.

Dla atakującego to nadal wygodne punkty do enumeracji. Spójne podejście oznacza:

• identyczną treść komunikatu przy resecie niezależnie od tego, czy e‑mail jest w bazie,
• neutralny komunikat przy próbie rejestracji na istniejący e‑mail (np. informacja wysłana mailem, nie na ekranie),
• formularz „zapomniany login” działający jak reset hasła – „jeśli taki adres istnieje, wysłaliśmy instrukcje”.

Dobrym kompromisem jest przesunięcie „szczegółów” do komunikacji e‑mailowej po stronie użytkownika, a front utrzymywanie w trybie „minimum informacji, maksimum ścieżek wyjścia”.

Jak dobrać poziom zabezpieczeń do swojego serwisu – prosta ścieżka decyzyjna

Trzy pytania, które porządkują temat

Zamiast kopiować konfigurację z zupełnie innego projektu, przejdź przez trzy krótkie pytania:

1. Ile realnie masz logowań dziennie i jak wrażliwe są dane? Inne podejście w sklepie z kosmetykami, inne w systemie do rozliczeń finansowych.
2. Czy w logach widać już ataki brute force / enumerację? Jeżeli tak – skąd pochodzą, jak często, jakiego typu?
3. Ile frustracji użytkownika jesteś w stanie zaakceptować? Czy kontakty z supportem po blokadach logowania będą dla ciebie dużym kosztem?

Na tej podstawie łatwiej dobrać zestaw:

• mały ruch + niska wrażliwość danych → neutralne komunikaty + lekkie throttlingi,
• średni ruch + częste ataki z masowych IP → throttling + limity per IP i konto + warunkowa CAPTCHA,
• duży ruch + wysoka wrażliwość danych → wszystkie powyższe + 2FA dla kluczowych kont + analiza behawioralna / WAF.

Bezpieczne formularze logowania i rejestracji nie muszą być skomplikowane. Sedno to: nie zdradzać, kogo masz w bazie, nie pozwalać na tysiące prób hasła z rzędu i nie karać uczciwych użytkowników za błędy, które prowokują atakujący. Jeśli przy każdej zmianie zadasz sobie pytanie „czy ta modyfikacja utrudnia życie botom, a nie moim klientom?”, konfiguracja zwykle sama układa się w sensowny zestaw.

Kluczowe Wnioski

• Formularze logowania, rejestracji i resetu hasła często działają jak darmowe API dla atakującego: pozwalają masowo sprawdzać, które loginy/e‑maile istnieją i testować do nich hasła.
• Różnicowanie komunikatów błędów („użytkownik nie istnieje” vs „złe hasło”) lub wyraźna różnica czasu odpowiedzi bezpośrednio umożliwia enumerację użytkowników, nawet bez dostępu do panelu administracyjnego.
• Neutralne, ujednolicone komunikaty („Nieprawidłowe dane logowania”) muszą być takie same niezależnie od tego, czy login istnieje, czy nie – to dotyczy logowania, resetu hasła i rejestracji.
• Mechanizmy resetu hasła i rejestracji są równie groźnym źródłem wycieków informacji jak samo logowanie – komunikaty typu „wysłaliśmy e‑mail z resetem” lub „konto już istnieje” nie mogą zdradzać, czy dany e‑mail jest w bazie.
• Brak throttlingu prób logowania (limitów na IP, konto, sieć) pozwala botom wykonywać tysiące prób na minutę, co łączy enumerację z credential stuffingiem i często kończy się realnym przejęciem kont.
• Samo dodanie CAPTCHA bez limitowania prób to proteza: dobre boty ją obchodzą, a prawdziwi użytkownicy najbardziej odczuwają irytację, nie wzrost bezpieczeństwa.
• Poziom „dokręcenia śruby” trzeba dobrać do wagi danych: w prostym sklepie można tolerować łagodniejsze limity, natomiast przy danych medycznych czy finansowych sensowne są ostrzejsze blokady i opóźnienia kosztem części wygody.