La politica delle password della sua organizzazione potrebbe ancora richiedere una lettera maiuscola, un simbolo e un cambio ogni 90 giorni. Il National Institute of Standards and Technology (NIST) statunitense ha abbandonato tutte e tre le regole. La sua guida attuale, la SP 800-63B-4, è stata finalizzata nel 2025 e sostituisce l’edizione 2020 della SP 800-63B.
Il NIST scrive queste linee guida per i sistemi federali statunitensi, ma sono un riferimento utile per qualsiasi organizzazione. Ecco cosa dicono e come applicarle.
Le regole sulle password nella SP 800-63B-4
La sezione 3.1.1.2 stabilisce i requisiti per i sistemi che verificano le password. Il NIST usa SHALL per i requisiti obbligatori e SHOULD per le raccomandazioni.
| Aspetto | Cosa dice il NIST |
|---|---|
| Lunghezza minima, solo password | Almeno 15 caratteri (SHALL) |
| Lunghezza minima, password come parte dell’MFA | Almeno 8 caratteri (SHALL) |
| Lunghezza massima | Consentire almeno 64 caratteri (SHOULD) |
| Caratteri | Accettare tutti i caratteri ASCII stampabili, gli spazi e Unicode (SHOULD) |
| Regole di composizione | Non imporle (SHALL NOT), ad esempio “una maiuscola, una cifra, un simbolo” |
| Cambi periodici | Non richiederli (SHALL NOT) |
| Compromissione nota | Imporre il cambio quando ci sono prove che la password sia compromessa (SHALL) |
| Blocklist | Confrontare le nuove password con valori noti, comuni, prevedibili o compromessi (SHALL) |
| Suggerimenti e domande di sicurezza | Non memorizzare suggerimenti né porre domande basate sulla conoscenza (SHALL NOT) |
| Password manager | Consentirli insieme alla compilazione automatica (SHALL); consentire l’incolla (SHOULD) |
| Tentativi falliti | Limitarne la frequenza (SHALL) |
| Troncamento | Verificare l’intera password così come è stata inserita (SHALL) |
Perché le vecchie regole sono state abbandonate
Le regole di composizione e la rotazione forzata sembrano rigorose, ma spingono le persone verso schemi prevedibili. Un utente costretto a cambiare Autumn2026! potrebbe benissimo scegliere Winter2026!, e un attaccante che conosce la vecchia password può indovinare la nuova.
Il NIST punta invece su lunghezza e blocklist. Una passphrase lunga è più facile da ricordare di una breve stringa casuale. La rotazione aiuta solo quando una password è già trapelata, quindi il NIST lega i cambi alle prove di compromissione anziché al calendario.
La blocklist sostituisce le regole di composizione come vero filtro. Rifiuta le password che gli attaccanti provano per prime: scelte comuni, parole legate alla sua organizzazione e password già comparse in violazioni di dati.
Il confronto con le password violate
Il servizio “Pwned Passwords” di Have I Been Pwned permette di confrontare una password con i dati delle violazioni senza inviare la password. Il sistema calcola l’hash SHA-1 della password e invia solo i primi cinque caratteri dell’hash. Il servizio restituisce tutti i suffissi di hash che iniziano con quei cinque caratteri, ciascuno con un conteggio, e il confronto avviene in locale.
# SHA-1 of "password" is 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
curl -s -H "Add-Padding: true" https://api.pwnedpasswords.com/range/5BAA6
Questo approccio, chiamato k-anonimato, fa sì che il servizio non sappia mai quale password è stata verificata. Una risposta tipica contiene diverse centinaia di suffissi, e l’header Add-Padding nasconde la dimensione reale della risposta a chiunque osservi il traffico. Per la ricerca per intervallo delle password non serve una chiave API.
Integri questo controllo nelle schermate di impostazione e modifica della password. Negli ambienti Active Directory, valuti strumenti che applicano un elenco di password violate ai cambi di password del dominio.
Consentire i password manager
Il NIST impone ai verificatori di consentire i password manager e la compilazione automatica. Ha senso: un password manager rende praticabili password lunghe e uniche, e le inserisce solo sul dominio in cui sono state salvate. Bloccare l’incolla nei moduli di login va nella direzione opposta.
Per il personale, fornisca un password manager aziendale invece di lasciare a ciascuno la scelta. Protegga il password manager stesso con una passphrase principale robusta e un’MFA resistente al phishing.
Non tutte le MFA sono uguali
Con un secondo fattore, una password rubata da sola non basta più, ma alcuni metodi possono comunque essere aggirati con il phishing. Una falsa pagina di login predisposta da un attaccante può chiedere un codice e inoltrarlo in tempo reale. Il NIST definisce la resistenza al phishing come la capacità del protocollo di impedire la divulgazione dei segreti senza dipendere dalla vigilanza dell’utente.
| Metodo | Resistente al phishing? | Note del NIST |
|---|---|---|
| Codice via SMS o chiamata vocale | No | Un autenticatore “con restrizioni”; i verificatori devono offrire alternative e dovrebbero monitorare SIM swap e portabilità del numero |
| Codice da app di autenticazione (TOTP) | No | I codici vengono digitati a mano, quindi possono essere inoltrati |
| Approvazione push o app fuori banda | No | I metodi fuori banda non sono resistenti al phishing |
| Codice o link via email | Non ammesso come metodo fuori banda | L’email non deve (SHALL NOT) essere usata per l’autenticazione fuori banda |
| Chiave di sicurezza o passkey FIDO2 / WebAuthn | Sì | La risposta è legata al nome del sito verificato |
Al livello di garanzia intermedio del NIST, AAL2, i verificatori devono (SHALL) offrire almeno un’opzione resistente al phishing. Al livello più alto, AAL3, l’autenticatore deve garantire la resistenza al phishing e usare una chiave privata non esportabile.
Passkey
Una passkey è una credenziale FIDO basata su WebAuthn. Il dispositivo crea una coppia di chiavi per ogni sito. Il sito conserva solo la chiave pubblica, mentre la chiave privata resta all’utente. La si sblocca con lo stesso metodo usato per sbloccare il dispositivo, come impronta digitale, volto o PIN. La FIDO Alliance precisa che i dati biometrici restano sul dispositivo e non vengono mai inviati al sito.
Poiché ogni passkey è legata a un solo sito, semplicemente non funziona su un dominio di phishing che lo imita. Inoltre sul server non c’è alcun segreto condiviso da rubare.
Le passkey esistono in due forme:
- Le passkey sincronizzate vengono copiate tra i dispositivi tramite il servizio di sincronizzazione di un provider. Il NIST le chiama autenticatori sincronizzabili e le ammette al livello AAL2. Poiché la chiave può essere esportata, non devono (SHALL NOT) essere usate al livello AAL3.
- Le passkey legate al dispositivo restano su un solo dispositivo, come una chiave di sicurezza hardware. Sono adatte agli amministratori e ad altri account ad alto rischio.
Pensi anche al recupero dell’account. Se qualcuno può reimpostare un account protetto da passkey con un link via email o una chiamata all’helpdesk, gli attaccanti possono semplicemente prendere di mira quella strada. Renda il recupero robusto almeno quanto l’accesso che sostituisce.
Una politica che può adottare
- Minimo 15 caratteri quando la password è l’unico fattore, e consentirne almeno 64.
- Nessuna regola di composizione e nessuna scadenza programmata.
- Confrontare ogni nuova password con un elenco di password violate e comuni.
- Imporre il cambio solo in presenza di prove di compromissione.
- Fornire un password manager e consentire incolla e compilazione automatica.
- Richiedere l’MFA ovunque sia disponibile, e un’MFA resistente al phishing per amministratori, email e accesso remoto.
- Introdurre le passkey dove i sistemi le supportano, iniziando dagli account ad alto rischio.
- Limitare la frequenza dei login falliti e rendere il recupero dell’account robusto quanto il login.
Da dove iniziare
Verifichi se una password compare già nei dati delle violazioni con il nostro strumento di verifica Pwned Passwords, e provi quanto deve essere lunga una passphrase con il nostro strumento sulla robustezza delle password.
Se sta rivedendo la sua politica sulle identità o pianificando l’introduzione delle passkey, il nostro team di consulenza può aiutarla a pianificarla.
