Returnează mesaje generice la eșecul autentificării, fără enumerare de conturi

Această practică implică returnarea unui mesaj de eroare identic, indiferent dacă utilizatorul a introdus un nume de utilizator incorect sau o parolă greșită. Este crucială deoarece, în absența ei, atacatorii pot folosi „enumerarea utilizatorilor” pentru a descoperi care adrese de email sunt înregistrate în sistem, facilitând ulterior atacuri de tip credential stuffing sau brute force. Ignorarea acestei reguli expune baza ta de date la risc, permițând criminalilor cibernetici să filtreze rapid conturile valide pentru a le exploata ulterior.

Cum o aplici

1. Centralizează logica de răspuns: În loc să ai condiții if/else separate pentru „utilizator inexistent” și „parolă incorectă”, creează o funcție helper care returnează întotdeauna același cod HTTP (de obicei 401 Unauthorized) și același mesaj text.
2. Loghează detaliile intern: Deși utilizatorul vede un mesaj generic, serverul trebuie să înregistreze detaliile exacte ale eșecului în jurnalele de audit (logs) pentru scopuri de monitorizare și depanare, fără a expune aceste informații în răspunsul HTTP.
3. Evită diferențele subtile: Asigură-te că timpul de răspuns al API-ului este constant. Dacă verificarea parolei durează mai mult decât verificarea existenței utilizatorului, un atacator poate deduce existența contului bazat pe latență. Folosește funcții de hash cu timp constant (cum ar fi bcrypt sau argon2) pentru a mitiga acest risc.

Exemplu

Varianta greșită expune informații sensibile:

// Răspuns pentru utilizator inexistent
{
  "error": "Utilizatorul nu a fost găsit"
}

// Răspuns pentru parolă greșită
{
  "error": "Parola este incorectă"
}

Varianta corectă, generică:

{
  "error": "Credențiale invalide. Verifică username-ul și parola."
}

Indiferent de motivul eșecului, clientul primește același obiect JSON și status code 401.

Cum verifici

• Teste manuale: Încearcă să te autentifici cu un email valid și parolă greșită, apoi cu un email invalid și o parolă arbitrară. Verifică dacă mesajele de eroare sunt identice.
• Analiza răspunsurilor HTTP: Folosește instrumente precum Postman sau curl pentru a inspecta corpul răspunsului. Nu ar trebui să conțină indicii despre starea contului.
• Monitorizarea logurilor: Confirmă că, deși mesajul afișat este generic, jurnalele serverului înregistrează distincția dintre „utilizator necunoscut” și „parolă incorectă” pentru a putea detecta activitate suspectă.

Greșeli frecvente

• Coduri HTTP diferite: Returnarea 404 Not Found pentru utilizatori inexistenți și 401 Unauthorized pentru parole greșite este o eroare comună care facilitează enumerarea.
• Mesaje ambigue dar distincte: Folosirea unor mesaje precum „Email incorect” vs. „Parolă incorectă” este tot o formă de enumerare, chiar dacă nu menționează explicit că utilizatorul nu există.
• Ignorarea timpului de răspuns: Dacă logica de verificare a parolei este lentă, iar cea a existenței utilizatorului este instantanee, atacatorii pot detecta conturile valide prin măsurarea latenței, chiar dacă mesajele text sunt identice.