Un attacco a dizionario non è semplicemente “provare tutte le parole del vocabolario italiano”. I moderni set di candidati possono contenere password provenienti da violazioni reali, sequenze numeriche, nomi propri, pattern di tastiera e trasformazioni che riproducono il modo in cui gli utenti cercano di soddisfare le regole di complessità.
È proprio per questo che Password1! può essere molto più debole di quanto suggeriscano maiuscola, numero e simbolo: è una trasformazione estremamente prevedibile di una parola comune.
Brute force e dictionary attack: differenza
Il brute force puro esplora sistematicamente uno spazio di combinazioni. Un attacco a dizionario cerca invece di ordinare i candidati per probabilità e provare prima ciò che gli esseri umani scelgono davvero.
Brute force:
aaaa
aaab
aaac
...
Dizionario/pattern:
password
password1
Password1!
azienda2026
nome+cognome
...Il secondo approccio non garantisce matematicamente di trovare qualsiasi segreto, ma contro password umane può essere immensamente più efficiente.
Le breach list hanno cambiato il significato di “dizionario”
Oggi esistono enormi corpus di password realmente utilizzate in passato. Questo significa che un attaccante non deve più indovinare soltanto quali parole possano piacere agli utenti: può partire da ciò che milioni di utenti hanno già scelto.
Da qui nasce anche una difesa importante: quando un utente crea o cambia password, il servizio dovrebbe rifiutare valori comuni, prevedibili o già compromessi.
Le regole di complessità creano trasformazioni prevedibili
Se imponiamo almeno una maiuscola, una cifra e un simbolo, gli utenti tendono a soddisfare il requisito nel modo più facile:
- maiuscola iniziale;
- anno o numero finale;
!come ultimo carattere;asostituita da@;osostituita da0.
Queste trasformazioni non sono casuali e possono essere incluse nelle strategie di guessing. È uno dei motivi per cui NIST Revision 4 vieta le composition rules obbligatorie per le password centrali.
Password spraying: un candidato contro molti utenti
Se un servizio blocca un account dopo molti errori, l’attaccante può ridurre la frequenza per singolo utente e provare la stessa password molto comune contro centinaia di account.
Un SOC o un sistema di monitoring deve quindi correlare eventi tra identità diverse. Dieci utenti che sbagliano una password una volta possono essere normali; dieci utenti diversi che ricevono lo stesso tipo di tentativo dalla stessa infrastruttura sono un segnale molto diverso.
Credential stuffing: non serve indovinare nulla
Nel credential stuffing vengono provate coppie email/password rubate in precedenza. Se l’utente ha riutilizzato la stessa credenziale, il tentativo può riuscire al primo colpo e non assomigliare affatto a un brute force rumoroso.
Questo spiega perché una password unica per ogni servizio è spesso più importante dell’aggiungere un altro simbolo a una password riutilizzata ovunque.
Difese lato utente
- password unica per ogni servizio;
- password manager;
- passphrase lunga quando dobbiamo ricordarla;
- MFA sugli account importanti;
- cambio immediato se una credenziale risulta compromessa.
Difese lato servizio
- blocklist di password comuni o compromesse;
- nessuna regola arbitraria di composizione;
- supporto a password lunghe e incolla/autofill dei password manager;
- rate limiting e detection trasversale tra account;
- MFA;
- hash sicuri e lenti per lo storage;
- alert su accessi riusciti dopo sequenze sospette.
Account enumeration
Messaggi differenti come “utente inesistente” e “password errata” possono aiutare a costruire un elenco di account validi. Dove il rischio lo giustifica, l’interfaccia di autenticazione dovrebbe evitare di regalare informazioni inutili sullo stato dell’identità.
Questo non significa sacrificare tutta l’usabilità in nome di messaggi vaghi: significa valutare consapevolmente quante informazioni esponiamo a un client non autenticato.
Il punto chiave
Un dizionario funziona perché le password umane non sono casuali. La difesa migliore non è inventare una nuova regola mnemonica più complicata, ma ridurre il bisogno di inventare password: generazione casuale nel password manager, unicità, MFA e controlli lato servizio.
Per il quadro completo dei diversi tipi di guessing vedi Brute force, password spraying e credential stuffing. Per la scelta e gestione delle credenziali vedi Password sicure.
Riferimenti
NIST SP 800-63B Revision 4 · OWASP Credential Stuffing Prevention.
