Una buona politica delle password non consiste nell’imporre il maggior numero possibile di regole. Deve soprattutto rendere i segreti difficili da indovinare, unici e praticabili per gli utenti.
GuidaBuone praticheIntermedio
Password: generazione, robustezza e politiche utili
Costruisci una policy basata su lunghezza, unicità e rischi reali invece che su regole di complessità arbitrarie.
Mostra indice
- La lunghezza conta molto
- Un indicatore di robustezza resta una stima
- Evitare regole che peggiorano il comportamento
- Lunghezza, imprevedibilità ed entropia
- La password deve soprattutto essere unica
- MFA e passkey modificano il modello di rischio
- Lato server: mai password in chiaro
- Politiche utente spiegabili
- Dopo una compromissione
La lunghezza conta molto
Una passphrase lunga e imprevedibile può essere migliore di una stringa breve piena di sostituzioni prevedibili. Quando la password non deve essere memorizzata, un generatore casuale è spesso la soluzione più semplice e robusta.
Un indicatore di robustezza resta una stima
Un controllo di robustezza può valutare lunghezza e composizione, ma nessun punteggio locale conosce tutti i dizionari, tutte le fughe di credenziali o il contesto di un attaccante.
Una password apparentemente forte ma già compromessa o riutilizzata su più servizi rimane pericolosa.
Evitare regole che peggiorano il comportamento
Imporre cambi molto frequenti senza incidente può incoraggiare varianti prevedibili. Richiedere sempre maiuscola, numero e simbolo non garantisce una forte entropia. Una policy moderna privilegia generalmente una lunghezza sufficiente, il blocco di password comuni o compromesse e l’autenticazione multifattore quando il rischio lo giustifica.
Le regole devono poter essere spiegate agli utenti e adattate al livello di rischio dell’applicazione.
Lunghezza, imprevedibilità ed entropia
La robustezza dipende soprattutto dallo spazio di ricerca che un attaccante deve esplorare. Aggiungere un carattere realmente casuale aumenta questo spazio; aggiungere sistematicamente 1! a una parola comune molto meno.
Per un segreto generato e conservato in un password manager, una stringa lunga e casuale è ideale. Per un segreto memorizzato, una passphrase lunga può offrire un buon compromesso tra sicurezza e usabilità.
La password deve soprattutto essere unica
Il riutilizzo trasforma la compromissione di un servizio in un rischio per molti altri. Una policy utile incoraggia quindi l’uso di password manager e, quando l’infrastruttura lo permette, il blocco di password note come compromesse.
Nessun punteggio di robustezza può compensare il riutilizzo dello stesso segreto ovunque.
MFA e passkey modificano il modello di rischio
L’autenticazione multifattore aggiunge una barriera quando la password viene compromessa. Non tutti i metodi MFA resistono allo stesso modo al phishing, ma una seconda prova ben progettata riduce molti scenari di attacco.
Le passkey utilizzano chiavi crittografiche invece di un segreto condiviso memorizzato. Possono ridurre phishing e riutilizzo, anche se le password rimangono ancora necessarie in molte applicazioni.
Lato server: mai password in chiaro
Un server non dovrebbe aver bisogno di recuperare la password originale. Deve conservarne il risultato tramite una funzione di derivazione specifica per password e un salt unico.
Funzioni come Argon2id, scrypt o bcrypt sono progettate per rendere costosi i tentativi massivi. Un hash rapido generico come SHA-256 usato da solo non è un sostituto adeguato.
Il salt non deve essere segreto: evita, tra le altre cose, che due utenti con la stessa password abbiano automaticamente la stessa impronta. Un eventuale pepper può aggiungere un segreto server, ma non sostituisce una funzione di derivazione corretta.
Politiche utente spiegabili
Una base moderna consiste nel definire una lunghezza minima ragionevole, accettare password lunghe, evitare scadenze periodiche senza motivo, bloccare segreti evidentemente deboli o compromessi e permettere il copia-incolla per non ostacolare i password manager.
Un’area amministrativa sensibile non richiede necessariamente la stessa policy di un servizio privo di dati importanti: la politica deve riflettere il rischio reale.
Dopo una compromissione
Se una password o un database di credenziali è sospettato di compromissione, non basta aumentare il requisito di complessità. Occorre invalidare gli accessi interessati, rinnovare i segreti, verificare le sessioni attive e comprendere la causa dell’incidente.
Una policy sulle password è quindi una componente della sicurezza Web complessiva, non una soluzione isolata.
Per distinguere derivazione delle password, crittografia, hash e autenticazione dei messaggi, continua con Crittografia, hashing e HMAC.