Cos'è il credential stuffing, e perché il solo rate limiting non basta a fermarlo

Se hai mai visto un picco improvviso di tentativi di login falliti contro un portale clienti o un sistema di prenotazione, è probabile che non fosse qualcuno che indovinava password. Era credential stuffing — e capire la differenza è importante, perché i due richiedono difese molto diverse.

Non è indovinare. È riprodurre.

Ogni violazione di dati su larga scala che espone coppie email/password finisce prima o poi per circolare in liste di massa — a volte miliardi di credenziali, aggregate da violazioni che non hanno nulla a che fare con la tua attività. Il credential stuffing prende quelle combinazioni email/password reali e note e le prova automaticamente contro il maggior numero possibile di pagine di login, scommettendo (in modo statisticamente molto ragionevole) che una percentuale significativa di persone riutilizzi la stessa password su più siti.

L’attaccante non sta cercando di violare il tuo sistema di login. Sta provando account che i tuoi clienti già possiedono, sperando che uno di loro abbia riutilizzato una password che non hai avuto alcun ruolo nel far trapelare.

Perché “basta aggiungere il rate limiting” non risolve del tutto il problema

Il rate limiting — bloccare un indirizzo IP dopo troppi tentativi falliti — è necessario, ma è pensato per un modello di minaccia diverso da quello che rappresenta davvero il credential stuffing:

È distribuito. Gli strumenti moderni di credential stuffing instradano i tentativi attraverso grandi pool di proxy residenziali o botnet, così nessun singolo IP supera mai una soglia sospetta.
È volutamente lento. Gli attacchi “low and slow” restano deliberatamente sotto le soglie di rate limiting, sacrificando la velocità per rimanere invisibili.
Non tocca la debolezza reale. Il rate limiting protegge l’endpoint di login. Non fa nulla riguardo al fatto che la password provata sia, di fatto, corretta.

Cosa aiuta davvero

L’autenticazione a più fattori, anche in un’implementazione di base, sconfigge del tutto il credential stuffing — una password corretta smette di essere sufficiente da sola.
Controllare le nuove password contro liste note di password violate in fase di registrazione o reset, così i clienti non scelgono inconsapevolmente una password già presente in un dump pubblico.
Il rilevamento comportamentale e basato sul dispositivo di anomalie, che cerca pattern come “questo login è riuscito ma da un dispositivo/posizione radicalmente incoerente con la storia di questo account” invece di limitarsi a contare i tentativi falliti.
Rate limiting e blocco account restano comunque importanti — alzano il costo dell’attacco e intercettano i tentativi meno sofisticati — semplicemente non come unico livello di difesa.

La parte scomoda del credential stuffing è che non richiede alcuna falla nel tuo sistema. La “vulnerabilità” è il riutilizzo delle password, che avviene interamente fuori dal tuo controllo — ed è esattamente per questo che la soluzione deve venire dal tuo lato, non sperando che i clienti sviluppino abitudini migliori con le password.