Raccomandazioni NIST 2025 sulle password: cosa è cambiato
Di CaptainDNS
Pubblicato il 20 febbraio 2026
- Il NIST vieta ora la scadenza periodica delle password, salvo in caso di compromissione accertata
- Le regole di complessità (maiuscola + numero + simbolo) sono abolite: in pratica peggiorano la sicurezza
- Minimo 8 caratteri obbligatori, 15 consigliati, e i sistemi devono accettare almeno 64 caratteri
- Ogni password deve essere verificata contro un database di credenziali compromesse (tipo Have I Been Pwned) prima dell'accettazione
- I suggerimenti per la password e le domande segrete sono vietati come meccanismi di recupero
Per anni, le policy sulle password aziendali seguivano la stessa ricetta: 8 caratteri minimi, una maiuscola, un numero, un simbolo e cambio ogni 90 giorni. Risultato: utenti che scelgono Primavera2025! a gennaio e Estate2025! ad aprile. Il NIST ha ufficialmente riconosciuto che questo approccio produce password più deboli, non più forti.
La revisione 4 del SP 800-63B, pubblicata nel 2024 e applicabile dal 2025, ribalta la maggior parte di queste pratiche. Questo documento è il riferimento federale americano per l'autenticazione digitale, ma la sua influenza va ben oltre i confini nazionali: ANSSI, BSI e OWASP allineano progressivamente le loro raccomandazioni.
Questo articolo analizza i cambiamenti concreti, spiega la logica dietro ogni decisione del NIST e fornisce un piano d'azione per adeguare la tua policy sulle password. Per testare subito la robustezza di una password, usa il nostro generatore di password con il suo indicatore di forza in tempo reale.
Cosa dice il NIST SP 800-63B-4
Il SP 800-63B fa parte della suite NIST SP 800-63 (Digital Identity Guidelines), che copre l'intero ciclo di vita dell'identità digitale. La revisione 4 sostituisce la versione 3 del 2017 e introduce cambiamenti importanti nella sezione dedicata ai "Memorized Secrets" (password e passphrase).
Portata del documento
Il SP 800-63B si rivolge ai fornitori di servizi di autenticazione (CSP, Credential Service Providers) e ai verificatori. Definisce tre livelli di garanzia (AAL1, AAL2, AAL3), ciascuno con requisiti crescenti. Le raccomandazioni sulle password si applicano principalmente al livello AAL1 (autenticazione a fattore singolo) e vengono riprese come base ai livelli superiori.
Gli 8 cambiamenti principali
La tabella seguente riassume le regole che cambiano tra la versione 3 (2017) e la versione 4 (2024/2025):
| Regola | SP 800-63B-3 (2017) | SP 800-63B-4 (2025) |
|---|---|---|
| Lunghezza minima | 8 caratteri | 8 obbligatorio, 15 consigliato |
| Lunghezza massima | Non specificata | 64 caratteri minimo supportato |
| Regole di complessità | Sconsigliate | Vietate (SHALL NOT) |
| Rotazione periodica | Sconsigliata | Vietata salvo compromissione |
| Verifica compromissioni | Consigliata | Obbligatoria (SHALL) |
| Suggerimenti password | Non menzionati | Vietati |
| Domande segrete | Sconsigliate | Vietate |
| Tutti i caratteri Unicode | Consigliato | Obbligatorio |
Il passaggio da "SHOULD NOT" (sconsigliato) a "SHALL NOT" (vietato) è significativo: non è più una raccomandazione, è un requisito di conformità.
Perché il NIST abolisce la rotazione obbligatoria?
La rotazione periodica delle password è la regola più controversa in sicurezza informatica. Il NIST la vieta ora esplicitamente, e la ragione è empirica.
Il problema documentato
Studi condotti all'Università della Carolina del Nord (Chappell et al.) hanno dimostrato che quando gli utenti sono costretti a cambiare regolarmente la password, adottano schemi prevedibili:
- Incremento:
Password1→Password2→Password3 - Rotazione stagionale:
Inverno2024!→Primavera2025! - Trasformazione minima:
IlMioGatto$→IlMioGatto$1→IlMioGatto$12
Un attaccante che ottiene una vecchia password può indovinare la successiva in meno di 5 tentativi nel 41% dei casi. La rotazione non aggiunge sicurezza, incoraggia la prevedibilità.
La nuova regola
La password deve essere cambiata solo in due casi:
- Compromissione accertata: la password compare in un database violato
- Richiesta dell'utente: cambio volontario
Gli amministratori devono rimuovere qualsiasi policy di scadenza automatica (90 giorni, 180 giorni, annuale). Il sistema deve comunque monitorare attivamente i database di compromissione e forzare un cambio se la password attuale vi compare.
Perché le regole di complessità sono controproducenti?
Richiedere "almeno una maiuscola, un numero e un simbolo" sembra logico sulla carta. In pratica, produce l'effetto opposto.
L'effetto perverso misurato
Quando un sistema impone regole di composizione, gli utenti convergono verso le stesse strategie:
- Maiuscola in prima posizione (95% dei casi)
- Numeri alla fine (89% dei casi)
- Simbolo:
!o@(78% dei casi)
Password1! soddisfa tutte le regole di complessità classiche. Viene craccata in meno di un secondo da qualsiasi tool di brute force che testa i pattern comuni. L'entropia teorica di una password vincolata è più elevata, ma l'entropia reale crolla perché gli esseri umani sono prevedibili.
Cosa raccomanda il NIST al posto delle regole di complessità
La lunghezza è il fattore dominante. Una password di 15 caratteri casuali senza vincoli di composizione offre più entropia di una password di 8 caratteri che rispetta tutte le regole di complessità. Il NIST chiede ai sistemi di:
- Accettare tutti i caratteri stampabili ASCII e Unicode (spazi inclusi)
- Non imporre regole di composizione
- Supportare almeno 64 caratteri (per consentire le passphrase)
- Normalizzare gli input Unicode (NFKC o NFKD) per evitare problemi di encoding
Verifica contro i database di password compromesse
È il cambiamento più tecnico. Ogni password scelta da un utente deve essere verificata contro una lista di credenziali compromesse prima di essere accettata.
Come implementare la verifica?
Il NIST non prescrive un'implementazione specifica, ma il metodo più diffuso usa il servizio Have I Been Pwned (HIBP) di Troy Hunt:
- Il sistema calcola l'hash SHA-1 della password candidata
- Invia i primi 5 caratteri dell'hash all'API HIBP (k-anonymity)
- L'API restituisce tutti gli hash corrispondenti
- Il sistema verifica localmente se l'hash completo è nella lista
Questo meccanismo preserva la riservatezza: la password non viene mai trasmessa in chiaro né sotto forma di hash completo. L'API HIBP contiene oltre 900 milioni di password uniche provenienti da leak reali.
Quando effettuare la verifica?
| Momento | Obbligatorio | Consigliato |
|---|---|---|
| Creazione account | Sì | - |
| Cambio password | Sì | - |
| Login | - | Sì (verifica periodica) |
Se la password viene trovata nel database di compromissione, il sistema deve rifiutarla con un messaggio chiaro che spiega il motivo e invita l'utente a sceglierne un'altra.
Cosa vieta esplicitamente il NIST
Oltre ai cambiamenti principali, diverse pratiche sono ora formalmente vietate:
Suggerimenti per la password
I campi "suggerimento" che mostrano un promemoria in caso di dimenticanza sono vietati. Espongono informazioni che aiutano un attaccante a indovinare la password. Un suggerimento come "nome del mio gatto + anno" riduce lo spazio di ricerca a poche migliaia di combinazioni.
Domande segrete
"Qual è il cognome da nubile di tua madre?" o "In quale città sei nato?": queste domande di knowledge-based authentication (KBA) sono vietate come unico fattore di recupero. Le risposte sono spesso reperibili sui social network o in database pubblici.
Troncamento della password
Un sistema non deve mai troncare la password a una lunghezza fissa prima dell'hashing. Se un utente inserisce 40 caratteri, tutti e 40 devono essere presi in considerazione. Il troncamento riduce silenziosamente l'entropia e crea un falso senso di sicurezza.
Hashing senza salt
Il NIST richiede che le password siano memorizzate con una funzione di hashing resistente (bcrypt, scrypt, Argon2id o PBKDF2) e un salt unico per utente. SHA-256 da solo non è accettabile: è troppo veloce e vulnerabile agli attacchi con rainbow table.
Confronto NIST, OWASP, ANSSI
Il NIST non è l'unico riferimento. Ecco come le sue raccomandazioni si confrontano con gli altri standard principali:
| Criterio | NIST SP 800-63B-4 | OWASP ASVS 4.0 | ANSSI (2021) |
|---|---|---|---|
| Lunghezza min. | 8 (15 consigliato) | 12 | 12 (16 per admin) |
| Lunghezza max. supportata | 64+ | 128 | Non specificato |
| Complessità | Vietata | Sconsigliata | Accettata a condizioni |
| Rotazione | Vietata salvo compromissione | Sconsigliata | 1 anno max |
| Verifica compromissioni | Obbligatoria | Consigliata | Non menzionata |
| MFA | Obbligatoria AAL2+ | Obbligatoria liv. 2+ | Consigliata |
| Domande segrete | Vietate | Vietate | Non menzionate |
I tre framework convergono sui principi fondamentali (lunghezza > complessità, niente rotazione inutile) ma divergono sul livello di esigenza. L'ANSSI resta più conservativa su complessità e rotazione. L'OWASP è più rigoroso sulla lunghezza minima.
🎯 Piano di conformità
Per gli amministratori di sistema e i CISO che devono adeguare la propria policy:
- Elimina la scadenza periodica: disattiva le policy di cambio a 90/180 giorni in Active Directory, LDAP o nel tuo IAM. Configura il monitoraggio delle compromissioni al loro posto
- Rimuovi le regole di composizione: elimina i requisiti "maiuscola + numero + simbolo". Aumenta la lunghezza minima a 15 caratteri e il massimo supportato ad almeno 64
- Integra la verifica HIBP: implementa la verifica k-anonymity alla creazione e al cambio di password. Usa un generatore di hash per verificare le tue implementazioni SHA-1
- Accetta tutti i caratteri: Unicode completo, spazi inclusi. Applica la normalizzazione NFKC prima dell'hashing
- Attiva l'MFA: la password da sola non basta. FIDO2/WebAuthn per gli account critici, TOTP come minimo per gli altri
- Documenta la tua policy: crea una policy scritta allineata al SP 800-63B-4 e comunica i cambiamenti agli utenti. Spiega perché non dovranno più cambiare la password regolarmente
FAQ
Cos'è il NIST SP 800-63B?
Il NIST SP 800-63B è un documento di riferimento pubblicato dal National Institute of Standards and Technology (NIST) americano. Fa parte della suite Digital Identity Guidelines e copre specificamente l'autenticazione e la gestione del ciclo di vita delle credenziali. La revisione 4, pubblicata nel 2024, è la versione in vigore e introduce cambiamenti significativi alle raccomandazioni sulle password.
Bisogna ancora cambiare la password regolarmente?
No. Il NIST vieta esplicitamente la scadenza periodica delle password (SHALL NOT). Una password deve essere cambiata solo se è compromessa (presente in un database violato) o se l'utente lo richiede volontariamente. Gli studi dimostrano che il cambio obbligatorio spinge gli utenti verso password prevedibili e più deboli.
Le regole di complessità sono ancora necessarie?
No. Il NIST vieta le regole di composizione ("almeno una maiuscola, un numero, un simbolo"). Queste regole producono pattern prevedibili (maiuscola all'inizio, numeri alla fine, simbolo !) che riducono l'entropia reale. La lunghezza è il fattore dominante: una password lunga e casuale è più sicura di una password corta e "complessa".
Qual è la lunghezza minima per una password nel 2025?
Il NIST impone un minimo di 8 caratteri e ne consiglia 15. L'OWASP e l'ANSSI consigliano 12. In pratica, punta a 15+ caratteri per gli account utente e 20+ per gli account amministratore. I sistemi devono accettare almeno 64 caratteri per consentire l'uso delle passphrase.
Come verificare se una password è compromessa?
Usa il protocollo k-anonymity con l'API Have I Been Pwned: calcola l'hash SHA-1 della password, invia i primi 5 caratteri dell'hash all'API e verifica se l'hash completo compare nei risultati. La password non viene mai trasmessa in chiaro. Questa verifica deve essere effettuata alla creazione dell'account e a ogni cambio di password.
Il NIST si applica al di fuori degli Stati Uniti?
Il SP 800-63B è uno standard federale americano, ma la sua influenza è mondiale. L'OWASP ne trae direttamente ispirazione, il BSI tedesco e l'ANSSI francese allineano progressivamente le loro raccomandazioni. Per le aziende internazionali o quelle che trattano dati di cittadini americani, seguire il NIST è uno standard de facto, anche senza un obbligo legale diretto.
Quale algoritmo di hashing usare per conservare le password?
Il NIST raccomanda Argon2id, bcrypt, scrypt o PBKDF2, con un salt unico per utente. SHA-256 o MD5 da soli sono inaccettabili: sono troppo veloci e vulnerabili agli attacchi con rainbow table e brute force GPU. Argon2id è la scelta raccomandata dall'OWASP nel 2025, con parametri di memoria e tempo adeguati alla tua infrastruttura.
Glossario
- SP 800-63B: Special Publication del NIST che definisce i requisiti di autenticazione digitale, parte B (Authentication and Lifecycle Management). La revisione 4 (2024) è la versione in vigore.
- AAL (Authentication Assurance Level): livello di garanzia dell'autenticazione definito dal NIST, da AAL1 (fattore singolo) ad AAL3 (hardware crittografico resistente al phishing).
- k-anonymity: tecnica crittografica che permette di verificare se un dato appartiene a un insieme senza rivelare il dato stesso. Utilizzata da Have I Been Pwned per la verifica delle password.
- Salt: valore casuale unico aggiunto alla password prima dell'hashing, che impedisce gli attacchi con tabelle precalcolate (rainbow table).
- Argon2id: funzione di hashing per password vincitrice della Password Hashing Competition (2015), resistente agli attacchi GPU e ASIC grazie al suo consumo di memoria configurabile.
Verifica la robustezza delle tue password ora: controlla se i tuoi URL sono sfruttati dal phishing con il nostro rilevatore di phishing, un complemento essenziale a qualsiasi policy sulle password solida.
📚 Guide correlate sulla sicurezza delle password
- Passkey vs password: vale la pena abbandonare le password nel 2025?
- Passphrase vs password: qual è davvero più sicura?
