Per molti anni il consiglio standard è stato: almeno otto o dieci caratteri, una maiuscola, una minuscola, un numero e un simbolo. Sembrava intuitivo: aumentando il numero di caratteri disponibili, aumentava anche lo spazio teorico delle combinazioni.
Il problema è che gli esseri umani non scelgono password in modo casuale. Quando imponiamo una maiuscola, molti la mettono all’inizio; quando imponiamo un numero, spesso finisce in fondo; quando chiediamo un simbolo compare !. Il risultato è una password formalmente “complessa” ma ancora molto prevedibile.
Le linee guida moderne hanno quindi cambiato prospettiva: lunghezza, unicità e resistenza agli attacchi reali contano più della ginnastica con i caratteri.
Una password deve resistere a più minacce diverse
Non esiste un’unica forma di “attacco alla password”. Una credenziale può essere:
- indovinata online provando molte combinazioni;
- trovata in un dizionario di password comuni;
- riutilizzata dopo una violazione di un altro sito;
- rubata con phishing o malware;
- recuperata offline dopo il furto del database degli hash.
Una password molto lunga aiuta contro il guessing e gli attacchi offline, ma non protegge dal phishing. Per questo una politica moderna non si ferma alla stringa scelta dall’utente.
Lunghezza prima della composizione
NIST SP 800-63 Revision 4 richiede almeno 15 caratteri quando la password è usata come unico fattore di autenticazione. Se la password fa parte di un processo MFA può essere più corta, ma non meno di otto caratteri. Il servizio dovrebbe inoltre consentire almeno 64 caratteri e permettere spazi e normali caratteri Unicode.
La stessa linea guida vieta di imporre regole del tipo “deve contenere almeno una maiuscola, un numero e un simbolo”. Non perché i simboli rendano una password più debole, ma perché obbligare gli utenti a usarli produce schemi estremamente prevedibili.
Passphrase: lunga e ricordabile
Quando dobbiamo ricordare personalmente una credenziale, una passphrase lunga composta da più parole non correlate può essere più pratica di una stringa corta piena di sostituzioni artificiose.
Il punto non è usare una frase famosa, una citazione o quattro parole che ci descrivono. Anche quelle possono finire in liste di guessing. Il vantaggio della passphrase arriva quando le parole sono sufficientemente lunghe e poco prevedibili nel loro insieme.
Per la maggior parte degli account: password manager
Un essere umano non dovrebbe cercare di ricordare cinquanta password forti e tutte diverse. Il risultato quasi inevitabile è il riuso oppure la creazione di variazioni minime della stessa base.
Un password manager permette invece di generare una credenziale casuale e unica per ogni servizio. In questo modello dobbiamo ricordare soprattutto la credenziale principale del manager e proteggere bene il dispositivo su cui lo utilizziamo.
Per gli account ad alto valore, il password manager va accompagnato da MFA e da una procedura di recupero documentata. Perdere l’unico dispositivo o l’unico recovery code non è una strategia di sicurezza particolarmente brillante.
Mai riutilizzare la stessa password
Il riuso trasforma una violazione locale in un problema globale. Se la stessa credenziale viene utilizzata su posta, VPN, e-commerce e server amministrativo, il sito meno protetto diventa indirettamente una porta verso tutti gli altri.
È il principio alla base del credential stuffing: l’attaccante non deve indovinare la password, gli basta provare credenziali già sottratte altrove. Una password unica per ogni servizio interrompe questa catena.
Non cambiare password “ogni 30/60/90 giorni” per abitudine
Le rotazioni periodiche obbligatorie sembravano una buona misura preventiva, ma spingono gli utenti verso schemi prevedibili come PasswordEstate2026! seguito da PasswordAutunno2026!.
Le linee guida moderne raccomandano di cambiare la password quando esiste un motivo: compromissione nota o sospetta, esposizione accidentale, incidente sul servizio oppure decisione dell’utente. Non semplicemente perché il calendario ha raggiunto il novantesimo giorno.
Blocklist: non accettare password già note
Un servizio dovrebbe confrontare le nuove password con una lista di valori comuni, prevedibili o già comparsi in violazioni note. Se l’utente sceglie password123, non serve calcolare quanta “entropia teorica” abbia: sappiamo già che è una scelta pessima.
Il controllo va fatto sulla password proposta, senza conservarla in chiaro e senza inviarla inutilmente a servizi esterni.
MFA: una password non dovrebbe essere l’unica barriera importante
Una password non è resistente al phishing. Se l’utente la inserisce su una pagina falsa, la sua lunghezza non cambia il risultato. Per account amministrativi, posta, VPN e servizi sensibili è quindi opportuno aggiungere un secondo fattore.
Quando possibile preferiamo metodi resistenti al phishing, come autenticazione basata su chiavi FIDO2/WebAuthn e passkey, rispetto a fattori che possono essere intercettati o social-engineered più facilmente.
Come deve conservare le password un’applicazione
Una password non va conservata in chiaro e, normalmente, nemmeno cifrata in modo reversibile. Il server deve memorizzare un verifier derivato con una funzione di password hashing lenta.
Per nuovi sistemi OWASP raccomanda Argon2id. Ogni password deve avere un salt casuale e unico; i parametri di costo devono rendere il calcolo abbastanza oneroso da rallentare un attacco offline, senza trasformare il login legittimo in un problema di performance.
// PHP, se Argon2id è disponibile
$hash = password_hash(
$password,
PASSWORD_ARGON2ID
);
if (password_verify($password, $hash)) {
// autenticazione valida
}Funzioni veloci come MD5, SHA-1 o SHA-256 usate direttamente sulla password non sono adatte allo storage delle credenziali: proprio la loro velocità aiuta l’attaccante a provare enormi quantità di candidati.
Rate limiting: difendersi dal guessing online
Online l’attaccante deve inviare ogni tentativo al nostro servizio. Possiamo quindi limitarlo. Delay progressivi, rate limiting, rilevamento di anomalie e MFA riducono drasticamente la velocità di guessing.
Il lockout rigido dopo pochi errori va progettato con attenzione: un aggressore potrebbe usarlo per bloccare deliberatamente gli account di altri utenti. È spesso preferibile combinare limiti progressivi, segnali di rischio e protezioni per account e sorgente.
Una password forte non risolve tutto
Keylogger, session hijacking, phishing, recovery debole e compromissione del dispositivo possono aggirare completamente una password eccellente. La credenziale è un elemento del sistema di autenticazione, non l’intero sistema.
Checklist pratica
- password lunga e unica per ogni servizio;
- password manager per le credenziali che non dobbiamo memorizzare;
- passphrase lunga quando dobbiamo ricordarla personalmente;
- MFA sugli account importanti;
- nessuna rotazione periodica senza motivo;
- blocklist di password compromesse o troppo comuni;
- rate limiting per gli accessi online;
- Argon2id o algoritmo equivalente per lo storage lato server;
- nessuna password in log, email o file di configurazione leggibili inutilmente.
Per capire cosa succede quando una credenziale viene indovinata sistematicamente, prosegui con Brute force, password spraying e credential stuffing.
Riferimenti
NIST SP 800-63B Revision 4 · OWASP Authentication Cheat Sheet · OWASP Password Storage Cheat Sheet.
