I suoi requisiti riguardano la lunghezza delle password, gli autenticatori sincronizzabili, i codici inviati via email, telefono e SMS e i timeout di sessione. Il materiale esaminato per questo articolo non definisce che cosa si intenda per «resistente al phishing». Per questo ci limitiamo a riportare ciò che dice il testo della linea guida e segnaliamo ogni volta che si tratta di una nostra interpretazione.
Che cos'è la linea guida del NIST sull'autenticazione e a chi si rivolge
Secondo la cronologia del documento riportata nella pagina della pubblicazione NIST su csrc.nist.gov, la versione definitiva della SP 800-63B-4 è datata 31 luglio 2025. Quando citiamo un requisito, indichiamo anche chi è tenuto a rispettarlo, perché la linea guida assegna gli obblighi a soggetti specifici.
Molti requisiti riguardano i verificatori e i CSP, cioè i soggetti nominati nella sezione sugli autenticatori del NIST su pages.nist.gov. Altri riguardano le agenzie federali. Il testo della linea guida NIST su pages.nist.gov, per esempio, stabilisce che le agenzie federali devono scegliere almeno l'AAL2 quando rendono disponibili online informazioni personali.
La nostra interpretazione: queste regole sono scritte per le organizzazioni che gestiscono i sistemi di accesso. Non sono istruzioni per chi possiede un conto presso un broker, un account su un exchange o una casella email. Possono comunque aiutare chi legge a capire quali opzioni di accesso offre un servizio e perché. Da sole, però, non mostrano come un determinato servizio protegga i propri utenti.
Password o MFA: che cosa chiede il testo alle password
Fra le affermazioni esaminate, la regola più chiara sulle password riguarda quelle usate da sole. Secondo la sezione sugli autenticatori del NIST su pages.nist.gov, i verificatori e i CSP devono richiedere che le password usate come meccanismo di autenticazione a fattore singolo siano lunghe almeno 15 caratteri.
Per un confronto storico, le FAQ del NIST sull'identità digitale descrivono il vecchio modello LOA. Secondo le FAQ, per quanto riguarda gli autenticatori, la differenza principale fra LOA1 e LOA2 era l'aumento della lunghezza minima della password da sei a otto caratteri.
| Regola nelle affermazioni esaminate | Fonte |
|---|---|
| Password a fattore singolo: almeno 15 caratteri, richiesti da verificatori e CSP | Sezione NIST sugli autenticatori |
| Vecchio modello LOA: la lunghezza minima della password passava da sei a otto caratteri fra LOA1 e LOA2 | FAQ del NIST |
La nostra interpretazione: quando la password è l'unico fattore, il testo attuale chiede un minimo molto più alto rispetto ai vecchi valori LOA. Le affermazioni esaminate non fissano una lunghezza specifica per le password usate come uno dei fattori in un sistema MFA, quindi non ne indichiamo una.
Passkey, autenticatori sincronizzabili e AAL3
Nelle affermazioni esaminate la parola «passkey» non compare mai. Compare invece una categoria affine, quella degli autenticatori sincronizzabili. Il testo della linea guida NIST su pages.nist.gov stabilisce che gli autenticatori sincronizzabili non devono essere usati all'AAL3, perché richiedono che la chiave privata sia esportabile.
In quella frase ci sono sia una regola sia la sua motivazione dichiarata:
- La regola: all'AAL3 gli autenticatori sincronizzabili sono esclusi.
- La motivazione dichiarata: richiedono che la chiave privata sia esportabile.
Ecco cosa non possiamo stabilire sulla base delle affermazioni esaminate:
- Se un determinato prodotto venduto o presentato come passkey sia un autenticatore sincronizzabile.
- Come la linea guida tratti gli autenticatori sincronizzabili a livelli diversi dall'AAL3.
- Se una qualsiasi passkey soddisfi una definizione di resistenza al phishing.
La nostra interpretazione: chi mette a confronto una passkey con un'MFA basata su password dovrebbe innanzitutto verificare se quella passkey sincronizza la propria chiave. La regola si basa proprio su questa caratteristica. Le affermazioni non vanno oltre, quindi lasciamo aperta la classificazione delle singole passkey.
Codici via email, SMS e telefono nell'accesso a più fattori
Nelle affermazioni esaminate compaiono diversi secondi passaggi molto diffusi. La sezione sugli autenticatori del NIST su pages.nist.gov stabilisce che l'email non deve essere usata per l'autenticazione out-of-band. La stessa sezione aggiunge che l'autenticazione out-of-band va considerata non valida se non viene completata entro 10 minuti.
I codici via telefono e SMS sono trattati nelle FAQ del NIST sull'identità digitale. Secondo le FAQ, gli autenticatori che si appoggiano alla rete telefonica pubblica commutata, compresi gli OTP inviati per telefono o via SMS, sono soggetti a restrizioni. Le affermazioni esaminate non spiegano che cosa comportino in pratica queste restrizioni, quindi non entriamo nel dettaglio.
| Metodo | Cosa dicono le affermazioni esaminate |
|---|---|
| Email per l'autenticazione out-of-band | Non deve essere usata |
| Autenticazione out-of-band in generale | Non valida se non completata entro 10 minuti |
| OTP via telefono e SMS | Soggetti a restrizioni |
La nostra interpretazione: con «MFA» si indicano diversi tipi di secondo passaggio, e la linea guida non li tratta tutti allo stesso modo. Chi osserva le opzioni di accesso di un account email, di un conto presso un broker o di un exchange può trovare utile questa distinzione. Queste regole però non dicono quale opzione usi un determinato servizio né quanto funzioni bene.
Timeout di riautenticazione all'AAL2 e all'AAL3
Anche le regole sulle sessioni cambiano a seconda del livello. Il testo della linea guida NIST su pages.nist.gov stabilisce che all'AAL2 deve essere impostato un timeout complessivo di riautenticazione ben definito, che dovrebbe essere di non più di 24 ore. All'AAL3 il timeout complessivo di riautenticazione non deve superare le 12 ore.
| Livello | Timeout complessivo di riautenticazione |
|---|---|
| AAL2 | Deve essere impostato; dovrebbe essere di non più di 24 ore |
| AAL3 | Non deve superare le 12 ore |
Attenzione alla formulazione. All'AAL2 il limite è espresso con «should» (dovrebbe), mentre all'AAL3 con «must» (deve). In questo articolo manteniamo la differenza e non presentiamo i due limiti come ugualmente vincolanti.
La nostra interpretazione: se un servizio vi chiede di accedere di nuovo dopo un certo periodo, questo può dipendere da una politica di timeout di questo tipo. Le affermazioni però non dicono come i singoli servizi impostino i propri timeout.
Che cosa è resistente al phishing e come valutare le affermazioni in merito
Le affermazioni esaminate, tratte dal testo della linea guida NIST su pages.nist.gov, non contengono una definizione di resistenza al phishing. Non dicono nemmeno se le passkey, gli autenticatori sincronizzabili o qualsiasi altro metodo ne soddisfino una. Lasciamo volutamente aperta la questione. Non prendiamo in prestito definizioni da sintesi secondarie che la revisione delle fonti non ha esaminato.
La stessa cautela vale per le affermazioni sulla sicurezza in generale. La guida di consigli rapidi del CERT.br osserva che una voce infondata ha di solito un tono allarmistico, riguarda argomenti che in quel momento attirano attenzione e non cita fonti, oppure cita fonti sconosciute. Secondo la nostra interpretazione ne deriva un'abitudine utile: quando un messaggio o un post sostiene che un metodo di accesso è sicuro o insicuro, cercate il testo originale su cui si basa e controllate se la formulazione dice «must» (deve), «should» (dovrebbe) o qualcosa di ancora meno vincolante.
Ecco a che cosa questo articolo può rispondere e a che cosa no:
- Risposte ricavate dalle affermazioni: regole sulla lunghezza delle password a fattore singolo, sull'email e sui tempi dell'autenticazione out-of-band, sui codici via telefono e SMS, sugli autenticatori sincronizzabili all'AAL3 e sui timeout di riautenticazione.
- Questioni aperte: una definizione di resistenza al phishing e la posizione delle singole passkey rispetto a essa.
Limiti di questo articolo
Questo articolo offre informazioni didattiche su linee guida di autenticazione pubblicate. Non costituisce una consulenza sugli investimenti e non raccomanda alcun prodotto, broker, exchange o servizio. Non tratta parti della linea guida del NIST oltre alle affermazioni qui elencate e non definisce la resistenza al phishing. Non valuta il modo in cui un determinato account o servizio protegge i propri utenti.