Dall’era delle password all’autenticazione resistente al phishing: la guida NIST

Il NIST ha rilasciato la versione finale della SP 800-63-4 Digital Identity Guidelines, di fatto le linee guida più autorevoli per l’uso delle password e della gestione delle identità digitali.

Questa quarta versione va ad aggiornare la precedente Special Publication NIST SP 800-63-3 pubblicata nel 2017.

Come per la precedente edizione, anche in questo caso la nuova revisione è suddivisa in quattro volumi, indicati con la revisione numero 4 e costituiti da oltre 400 pagine in totale:

• SP 800-63-4 Digital Identity Guidelines (86 pagine);
• SP 800-63A-4 Identity Proofing & Enrollment (102 pagine);
• SP 800-63B-4 Authentication & Authenticator Management (118 pagine);
• SP 800-63C-4 Federation & Assertions (137 pagine).

Tutti i documenti sono scaricabili gratuitamente dal sito del NIST.

Questa nuova versione è frutto di oltre quattro anni di lavoro, due bozze pubbliche e circa 6.000 commenti dal pubblico.

Il primo “PRE-DRAFT Call for Comments” di questo documento fu pubblicato a giugno 2020, mentre la prima bozza è datata 16 dicembre 2022, quando il NIST ha pubblicato l’Initial Public Draft (IPD) del documento SP 800-63, Revisione 4.

Sulla base dei commenti e delle osservazioni raccolte, ora il NIST ha rilasciato nel 2025 questa versione finale, che – come sempre – rappresenta un riferimento fondamentale a livello mondiale per la gestione dell’identità digitale e i sistemi di autenticazione. Inoltre promuove soluzioni di autenticazione resistenti al phishing.

Cosa è la NIST Special Publication 800-63: la storia

NIST (National Institute of Standards and Technology) è un’agenzia del governo degli Stati Uniti d’America che si occupa della gestione delle tecnologie. Fa parte del DoC, Department of Commerce (Ministero del Commercio).

Ha come compito istituzionale quello di di sviluppare standard tecnologici.

NIST pubblica – tra gli altri – i Federal Information Processing Standard (FIPS), che definiscono gli standard obbligatori del governo statunitense.

La serie NIST SP (Special Pubblication) 800 è un insieme di documenti che descrivono le politiche, le procedure e le linee guida del governo federale degli Stati Uniti per i sistemi e le reti informatiche e per la sicurezza informatica.

La Special Publication 800-63 definisce le linee guida del NIST sui sistemi di autenticazione e sulle password, rappresenta il documento più importante ed autorevole su questa delicata materia a livello mondiale.

Vediamo la sua storia:

• SP 800-63 Electronic Authentication Guideline: pubblicata nel giugno 2004. Gli autori di questa prima edizione erano William Burr (NIST), Donna Dodson (NIST), W. Polk (NIST);
• SP 800-63-1 Electronic Authentication Guideline: pubblicata nel dicembre 2011; ha aggiornato la precedente per riflettere le attuali tecnologie degli autenticatori (allora indicati come “token”).
• SP 800-63-2 Electronic Authentication Guideline: pubblicata nell’agosto 2013. È stato un aggiornamento limitato della SP 800-63-1 e sono state apportate modifiche sostanziali solo alla sezione 5, Processi di registrazione e rilascio;
• SP 800-63-3 Digital Identity Guidelines: pubblicata nel giugno 2017. Si è trattato di un aggiornamento molto sostanziale dell’SP 800-63-2. L’SP 800-63-3 introduce i singoli componenti della garanzia dell’autenticazione digitale – AAL (Authentication Assurance Level), IAL (Identity Assurance Level) e FAL (Federation Assurance Level) – per supportare la crescente necessità di un trattamento indipendente della forza dell’autenticazione e della fiducia nell’identità dichiarata di un individuo (ad esempio, nell’autenticazione forte). Include una metodologia di valutazione del rischio e la sua applicazione a IAL, AAL e FAL.

Inoltre, l’intera SP 800-63 cambia nome in “Digital Identity Guidelines” (guida sull’identità digitale) e passa da un singolo documento che descrive l’autenticazione a una suite di quattro volumi: si aggiungono i tre “companion volumes” SP 800-63A, SP 800-63B, SP 800-63C.

Linee guida per l’identità digitale: com’è strutturata la NIST SP 800-63-4

Come abbiamo detto, è composta da 4 volumi.

Nel primo SP 800-63-4 Digital Identity Guidelines, che è il corpo principale, sono riportate molte considerazioni generali e viene specificato l’ambito di applicazione: “La presente guida si applica a tutti i servizi online per i quali è richiesto un certo livello di identità digitale, indipendentemente dal gruppo di utenti (ad esempio, residenti, partner commerciali ed enti governativi). In questa pubblicazione, il termine “persona” si riferisce solo alle persone fisiche”.

Viene indicata la metodologia di valutazione del rischio e il processo di selezione dei livelli di garanzia per la verifica dell’identità, l’autenticazione e la federazione.

La sezione 1 fornisce un’introduzione al documento.

La sezione 2 descrive un modello generale di identità digitale.

La sezione 3 descrive il modello di rischio dell’identità digitale.

Nella sezione “References” sono elencati i riferimenti normativi e le pubblicazioni citate in questo documento.

Tra i riferimenti citati troviamo altri documenti NIST, tra i quali la fondamentale SP 800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations.

Vengono richiamati anche il NIST Privacy Framework (NISTPF) e la SP 800-122Guide to Protecting the Confidentiality of Personally Identifiable Information (PII).

L’Appendice A contiene un elenco delle abbreviazioni e acronimi (molto utili).

L’Appendice B contiene un glossario di termini utilizzati in questo documento. Riportiamo qui alcuni degli acronimi più importanti e maggiormente presenti nella SP 800-63-4, che quindi è utile conoscere:

1. IAL identity assurance level: categoria che trasmette il grado di fiducia che l’identità dichiarata del soggetto sia la sua vera identità.
2. AAL authentication assurance level: categoria che descrive la forza del processo di autenticazione.
3. FAL federation assurance level: categoria che descrive il processo utilizzato in una transazione di federazione per comunicare eventi di autenticazione e attributi di un utente (subscriber) a un RP (subscriber account).

L’Appendice C contiene un elenco sintetico delle modifiche apportate nella storia della SP 800-63, come abbiamo già sopra descritto.

Gli altri tre documenti sono definiti “companion volumes”, cioè volumi di accompagnamento e di approfondimento. Ne elenchiamo in sintesi i contenuti:

1. SP 800-63A Identity Proofing & Enrollment fornisce i requisiti per la verifica dell’identità e l’iscrizione dei richiedenti, da remoto o di persona, che desiderano accedere alle risorse di ciascuno dei tre IAL (Identity Assurance Level). Descrive in dettaglio le responsabilità dei CSP (Credential Service Provider) per quanto riguarda la creazione e il mantenimento degli account degli abbonati e il collegamento degli autenticatori emessi dal CSP o forniti all’account dell’abbonato. Il documento SP 800-63A contiene materiale normativo e informativo.
2. SP 800-63B Authentication & Authenticator Management fornisce i requisiti per i processi di autenticazione, compresa la scelta degli autenticatori, che possono essere utilizzati in ciascuno dei tre AAL. Fornisce inoltre raccomandazioni sugli eventi che possono verificarsi durante la vita degli autenticatori, compresa l’invalidazione in caso di perdita o furto. SP 800-63B contiene sia materiale normativo che informativo. È la sezione che contiene le nozioni ed i consigli più pratici ed utili per l’utilizzo delle password e dell’autenticazione forte (MFA). Ne illustreremo in seguito i punti più interessanti.
3. SP 800-63C Federation & Assertions fornisce requisiti sull’uso di architetture di identità federate e asserzioni per trasmettere i risultati dei processi di autenticazione e le informazioni rilevanti sull’identità a un’applicazione dell’agenzia. Questo volume offre tecniche di miglioramento della privacy per la condivisione di informazioni su un soggetto valido e autenticato e descrive metodi che consentono una autenticazione a più fattori (MFA).

In ognuno dei quattro volumi della SP 800-63-4, nel primo capitolo (Introduction) è sempre presente un paragrafo Notations, dove sono spiegate con grande chiarezza le convenzioni tipografiche utilizzate nel testo:

• i termini specifici in MAIUSCOLO rappresentano requisiti normativi. Quando gli stessi termini non sono in MAIUSCOLO, il termine non rappresenta un requisito normativo;
• i termini “DEVE” (“SHALL”) e “NON DEVE” (“SHALL NOT”) indicano requisiti da seguire rigorosamente per essere conformi alla pubblicazione e dai quali non è consentita alcuna deviazione;
• itermini “DOVREBBE” (“SHOULD”) e “NON DOVREBBE” (“SHOULD NOT”) indicano che tra diverse possibilità, una è raccomandata come particolarmente adatta senza menzionarne o escluderne altre, che una certa linea d’azione è preferita ma non necessariamente richiesta, o che (nella forma negativa) una certa possibilità o linea d’azione è scoraggiata ma non proibita;
• i termini “POSSIBILE” (“MAY”) e “NON NECESSARIO” (NEED NOT”) indicano una linea d’azione ammissibile entro i limiti indicati nella linea guida;
• i termini “PUÒ” (“CAN”) e “NON PUÒ” (“CANNOT”)  indicano una possibilità e una capacità materiale, fisica o causale o, in negativo, l’assenza di tale possibilità o capacità.

Come sempre, i documenti del NIST sono redatti in modo molto comprensibile!

Linee guida NIST per l’identità digitale: gli aspetti più interessanti

Una novità principale è il passaggio da un approccio basato su checklist a un framework di Digital Identity Risk Management (DIRM), che richiede alle organizzazioni di valutare continuamente minacce, impatti sui servizi e popolazioni utente per selezionare dinamicamente i livelli di assurance (IAL, AAL, FAL).

Un altro aspetto che viene molto enfatizzato è il concetto di “autenticazione resistente al phishing”: è noto che l’autenticazione con la sola password, per quanto robusta, non è resistente al phishing, cioè all’errore umano.

Per questo motivo, le linee guida della SP 800-63-4 promuovono fortemente autenticatori resistenti al phishing, integrando passkey FIDO2 per i livelli AAL2 e AAL3, e scoraggiano OTP e SMS, sistemi deprecati perché considerati vulnerabili a social engineering o SIM swapping.

Quindi SP 800-63-3 e SP 800-63-4 mantengono la stessa struttura di base (a suite di quattro volumi A/B/C e livelli IAL, AAL, FAL), ma la SP 800-63-4 introduce un approccio molto più orientato alla gestione del rischio, all’accessibilità e a metodi di autenticazione moderni come le passkey resistenti al phishing.

In pratica, 63-4 è un’evoluzione che aggiorna i controlli per l’era delle passkey, dei wallet di credenziali e delle minacce moderne, senza stravolgere il modello concettuale introdotto con 63-3.

Nuove raccomandazioni per autenticazione resistente al phishing

Le nuove linee guida SP 800-63-4 rendono di fatto l’autenticazione resistente al phishing la raccomandazione standard per AAL2 e un requisito obbligatorio per AAL3, con forte enfasi su passkey FIDO2 e chiavi hardware con chiavi private non esportabili.

In pratica, password + OTP (soprattutto via SMS) restano tollerate solo in scenari a rischio più basso, mentre per applicazioni critiche viene richiesto l’uso di metodi che non possano essere intercettati o riutilizzati.

Cosa significa “phishing‑resistant”

Un autenticatore è considerato resistente al phishing se lega la risposta crittografica al canale o al nome del verificatore, impedendo che venga riusata su un sito o canale diverso.

Esempi tipici sono FIDO2/WebAuthn passkey, smart card e security key hardware, che firmano una challenge legata al dominio legittimo e richiedono una prova di intenzione dell’utente (PIN/biometria).

In molti punti si fa riferimento ai livelli AAL (authentication assurance level): questi sono spiegati in dettaglio nella SP 800-63B che, tra i quattro volumi delle linee guida, è quello che contiene le nozioni ed i consigli più pratici ed utili per l’utilizzo delle password e dell’autenticazione forte (MFA).

Li vediamo illustrati al cap.2.5 Summary of requirements, nell’immagine sottostante.

• AAL1 fornisce la sicurezza di base che è legata all’account dell’abbonato. AAL1 richiede l’autenticazione a fattore singolo o a più fattori utilizzando una vasta gamma di tecnologie di autenticazione disponibili. I verificatori DOVREBBERO rendere disponibili opzioni di autenticazione a più fattori presso AAL1 e incoraggiarne l’uso. L’autenticazione riuscita richiede che il richiedente dimostri il possesso e il controllo dell’autenticatore attraverso un protocollo di autenticazione sicuro.
• AAL2 deve offrire un’opzione di autenticazione resistente al phishing, anche se possono coesistere metodi meno robusti (es. OTP app, SMS) per garantire copertura completa degli utenti.
• Le passkey sincronizzate (multi‑device) sono esplicitamente riconosciute come phishing‑resistant idonee per AAL2, a condizione che siano implementate secondo le indicazioni NIST (gestione sicura della sincronizzazione e del dispositivo).
• AAL3 richiede autenticazione resistente al phishing con chiave privata non esportabile, tipicamente device‑bound (hardware key, secure enclave, smart card), con verifica locale dell’utente.

Le passkey sincronizzate non sono accettate per AAL3 proprio perché comportano esportabilità delle chiavi; per questi casi sono raccomandati token hardware dedicati o passkey legate in modo esclusivo a un singolo dispositivo.

Cosa viene sconsigliato

OTP via SMS, e-mail o chiamata vocale, così come push “approva/nega”, sono classificati come non resistenti al phishing e non soddisfano le aspettative per i casi d’uso ad alto impatto.

Per ambienti che oggi usano password + OTP, la raccomandazione è pianificare una migrazione graduale verso passkey FIDO2 o smart card/security key, almeno per amministratori, accessi remoti e applicazioni ad alto rischio di frode.

Vengono quindi indicate linee guida pratiche per migrare gli utenti da OTP a FIDO2: secondo la SP 800-63-4, la migrazione da OTP (SMS, e‑mail, TOTP) a FIDO2/passkey va fatta in modo graduale: si parte da un pilota limitato, si estende alle utenze a rischio più alto e solo alla fine si “spengono” gli OTP lasciandoli solo come “fallback di emergenza”, limitati a casi specifici (recupero account, utenti legacy, scenari low‑risk); per applicazioni ad alto impatto si deve prevedere solo FIDO2.

In questo processo, viene anche consigliato di pianificare fin da subito processi per smarrimento, sostituzione e revoca delle chiavi FIDO2.

SP 800-63B Authentication & Authenticator Management: punti di interesse

Il volume SP 800-63B-4 è – come nelle precedenti versioni – il più ricco di informazioni tecniche ed è molto ampio (118 pagine in tutto).

Riportiamo qui solo alcuni dei punti più interessanti, rimandando ad una lettura più completa per maggiori dettagli.

Il volume si concentra sull’autenticazione dei soggetti che interagiscono con i sistemi informativi governativi sulle reti per stabilire che un determinato richiedente è un abbonato che è stato precedentemente autenticato. Il risultato del processo di autenticazione può essere utilizzato localmente dal sistema che esegue l’autenticazione o utilizzato altrove in un sistema di identità federato. Definisce i requisiti tecnici per ciascuno dei tre livelli di garanzia di autenticazione.

Misure di sicurezza da adottare per la corretta autenticazione

Uno dei capitoli più interessanti è il 3. Authenticator and Verifier Requirements dove vengono elencate le misure di sicurezza da adottare.

I “Type of Secret” sono elencate nella Table 2. Summary of secrets:

Standard per l’utilizzo corretto delle password

Nel capitolo 3.1.1 Passwords vengono definiti gli standard per l’utilizzo corretto delle password.

La definizione che ne viene data è: “una password (talvolta definita passphrase o, se numerica, PIN) è un valore segreto destinato a essere scelto e memorizzato o registrato dall’utente. Le password devono avere una complessità e una segretezza tali da rendere impossibile per un malintenzionato indovinare o scoprire in altro modo il valore segreto corretto. Una password è “qualcosa che si conosce”.

Le password utilizzate localmente come fattore di attivazione per un autenticatore a più fattori (MFA) sono denominate Activation Secrets (segreti di attivazione) e sono trattate nella Sezione 3.2.10.

Viene detto che: “Un segreto di attivazione viene utilizzato per ottenere l’accesso a una chiave di autenticazione memorizzata. In tutti i casi, il segreto di attivazione DEVE rimanere all’interno dell’autenticatore e del suo endpoint utente associato”.

Qual è la corretta lunghezza di una password

Molto interessante quanto riportato nell’Appendice A Strength of Passwords.

Le password sono una forma di autenticazione ampiamente utilizzata nonostante le preoccupazioni sul loro utilizzo sia dal punto di vista dell’usabilità che della sicurezza.

Si riafferma un concetto ormai ben noto: “Gli esseri umani hanno una capacità limitata di memorizzare segreti complessi e arbitrari, quindi, spesso scelgono password che possono essere facilmente indovinate.

Per affrontare i conseguenti problemi di sicurezza, i servizi online hanno introdotto regole che aumentano l’efficacia di queste password. La forma più notevole sono le regole di composizione, che richiedono agli utenti di scegliere password costruite utilizzando un mix di tipi di caratteri (ad esempio, almeno una cifra, lettera maiuscola e simbolo). Tuttavia, le analisi dei database di password violate rivelano che il beneficio di tali regole è meno significativo di quanto inizialmente pensato”.

Si ribadisce che “le password non sono resistenti al phishing” (concetto importante, ma non a tutti noto!) ed anche: “Molti attacchi associati all’uso delle password non sono influenzati dalla complessità e dalla lunghezza delle stesse. Gli attacchi di keystroke logging (keylogger cioè registrazione dei tasti), phishing e social engineering sono altrettanto efficaci con le password lunghe e complesse che con quelle semplici”.

NIST mette in discussione anche il concetto di entropia (di una password), enunciato da Claude Shannon. Mentre l’entropia può essere facilmente calcolata per i dati con funzioni di distribuzione deterministiche, stimare l’entropia delle password scelte dagli utenti è difficile e i tentativi fatti in passato non sono stati particolarmente accurati. Per questo motivo, NIST consiglia un approccio diverso e un po’ più semplice, basato principalmente sulla lunghezza della password.

Regole basilari per la creazione di una password

Al punto 3.1.1.2 Password Verifiers sono elencate le regole basilari da applicare alle password:

1. I verificatori e i CSP DEVONO richiedere che le password utilizzate come meccanismo di autenticazione a fattore singolo siano lunghe almeno 15 caratteri. I verificatori e i CSP POSSONO consentire che le password utilizzate solo come parte dei processi di autenticazione a più fattori siano più brevi, ma DEVONO richiedere che siano lunghe almeno otto caratteri.
2. I verificatori e i CSP DEVONO consentire una lunghezza massima della password di almeno 64 caratteri.
3. I verificatori e i CSP DOVREBBERO accettare tutti i caratteri ASCII di stampa e il carattere spazio nelle password.
4. I verificatori e i CSP DEVONO accettare nelle password i caratteri Unicode [ISO/ISC 10646]. Ogni carattere di codice Unicode DEVE essere contato come un singolo carattere nella valutazione della lunghezza della password.
5. I verificatori e i CSP NON DEVONO imporre altre regole di composizione (ad esempio, richiedere miscele di tipi di caratteri diversi) per le password.
6. I verificatori e i CSP NON DEVONO richiedere agli utenti di cambiare le password periodicamente. Tuttavia, i verificatori DEVONO imporre una modifica se vi sono prove di compromissione dell’autenticatore.
7. I verificatori e i CSP NON DEVONO permettere all’utente di memorizzare un suggerimento accessibile a un richiedente non autenticato.
8. I verificatori e i CSP NON DEVONO chiedere agli abbonati di utilizzare l’autenticazione basata sulla conoscenza (KBA, Knowledge-Based Authentication) (ad esempio, “Qual era il nome del tuo primo animale domestico?”) o domande di sicurezza quando scelgono le password.
9. I verificatori DEVONO richiedere che la password venga fornita per intero (non un sottoinsieme di essa) e DEVONO verificare l’intera password inviata (ad esempio, non troncarla).

Le regole espresse dalla SP 800-63B, che abbiamo qui sintetizzato, sono in realtà indicazioni di buon senso, alcune addirittura ovvie. Ma non sempre applicate, purtroppo.

Vediamo che la lunghezza minima per la password dovrebbe essere di almeno 8 caratteri, ma deve essere consentita una lunghezza massima di almeno 64 caratteri. Ed anche: tutti i caratteri ASCII dovrebbero essere accettati.

È imbarazzante vedere ancora oggi molti siti che impongono lunghezze massime risibili e che addirittura non accettano i caratteri speciali! Questa limitazione, da considerarsi non più accettabile, è spesso causata dall’utilizzo di sistemi “legacy” (antiquati) che non permettono l’uso di password più lunghe di 8 caratteri e/o non accettano i caratteri speciali (o ne accettano solo alcuni).

E neppure (punto 5) dovrebbero essere imposte “regole di composizione”, come quelle che richiedono, per esempio, “un numero ed un carattere speciale”. Tali regole indicano un pattern di composizione all’attaccante che intenda provare un attacco brute force.

Il punto 6 è particolarmente interessante: NIST sostiene che obbligare arbitrariamente le persone a cambiare periodicamente le password non è più considerata una pratica utile, anzi può portare l’utente ad utilizzare password banali per riuscire a ricordarle più facilmente (ogni volta che si è obbligati a cambiarle).

In altre parole, le politiche di scadenza delle password fanno più male che bene, perché inducono gli utenti ad impostare password molto prevedibili e strettamente correlati tra loro: quindi la password successiva può essere dedotta sulla base della password precedente.

Si aggiunge tuttavia che la password andrebbe comunque cambiata se c’è il sospetto o l’evidenza di una sua compromissione.

Questa regola ancora oggi non viene recepita dalla grande maggioranza delle aziende e dei siti che continuano ad imporre il cambio periodico della password, magari imponendo password di lunghezza limitata (policy contraria al consiglio n.2 sopra indicato).

Il NIST depreca le “domande di sicurezza”

Nel punto 8 NIST depreca le “famigerate” domande di sicurezza, che invita a non richiedere.

Tali domande sono in genere di questo tipo:

• Il nome del tuo primo animale?
• La tua squadra del cuore?

Le risposte saranno molto banali e chi ci conosce potrebbe facilmente indovinarle.

Inoltre, si richiede ai verificatori, quando elaborano una richiesta di creazione o modifica di una password, di controllare che questa non sia presente in blocklist, dove sono elencate le password conosciute, comunemente utilizzate, previste o compromesse. Ad esempio, l’elenco potrebbe includere, a titolo esemplificativo e non esaustivo:

• password ottenute da precedenti database di violazioni,
• parole a dizionario,
• parole specifiche del contesto, come il nome del servizio, il nome utente e i suoi derivati.

Il consiglio del NIST: usare i password manager

Nello stesso paragrafo vengono consigliati i password manager: “I verificatori DEVONO consentire l’uso di gestori di password. I verificatori DOVREBBERO consentire ai richiedenti di utilizzare la funzionalità “incolla” quando inseriscono una password per facilitarne l’uso. È stato dimostrato che i gestori di password aumentano la probabilità che gli utenti scelgano password più forti, in particolare se i gestori di password includono generatori di password.”

E anche: “Per aiutare il richiedente a inserire correttamente la password, il verificatore DOVREBBE offrire l’opzione di visualizzare il segreto (la password) – anziché una serie di punti o asterischi – durante l’inserimento e fino all’invio al verificatore. Ciò consente al richiedente di confermare la propria immissione se si trova in un luogo in cui è improbabile che il suo schermo venga osservato. Il verificatore PUÒ anche consentire al dispositivo del richiedente di visualizzare i singoli caratteri immessi per un breve periodo di tempo dopo la digitazione di ciascun carattere per verificare la correttezza dell’immissione.”

Sono indicazioni elementari e di buon senso, ma le due funzionalità (incolla e visualizza in chiaro la password) sono purtroppo disattese da alcuni servizi web. In questi casi diventa estremamente scomodo per l’utente l’uso di una password lunga e complessa, da digitare “alla cieca”. Questi finirà – inevitabilmente – per optare per password più semplici e quindi meno sicure.

Le misure consigliate per l’autenticazione multifattore

Nel paragrafo 3.1.4.Single-Factor OTP sono indicate le misure consigliate per l’autenticazione a singolo fattore con OTP (one-time password), ma si precisa che l’autenticazione OTP a fattore singolo è “qualcosa che hai”, ma non è resistente al phishing.

Nel successivo 3.1.5.Multi-Factor OTPs sono illustrati i vari sistemi di MFA con dispositivi hardware e generatori OTP basati su software installati su telefoni cellulari e dispositivi simili. Anche in questo caso NIST segnala che l’autenticazione OTP non è resistente al phishing, mentre lo è l’autenticazione crittografica, descritta nei successivi paragrafi 3.1.6.Single-Factor Cryptographic Authentication e 3.1.7. Multi-Factor Cryptographic Authentication.

L’autenticazione crittografica a più fattori utilizza un protocollo di autenticazione per dimostrare il possesso e il controllo di una chiave crittografica che richiede l’attivazione attraverso un secondo fattore di autenticazione.

A seconda della forza dell’autenticazione necessaria, la chiave privata o simmetrica può essere memorizzata in un modo accessibile all’endpoint da autenticare o in un processore o dispositivo separato, direttamente collegato, dal quale la chiave non può essere esportata.

L’output dell’autenticatore dipende in larga misura dallo specifico protocollo crittografico utilizzato, ma in genere è un tipo di messaggio firmato. Un autenticatore crittografico a più fattori è “qualcosa che si possiede” e viene attivato (cioè sbloccato) da un fattore di attivazione che rappresenta “qualcosa che si conosce” o “qualcosa che si è”.

L’autenticazione resistente al phishing

L’autenticazione crittografica è resistente al phishing se soddisfa i requisiti aggiuntivi di cui al punto 3.2.5.Phishing Resistance.

Gli attacchi di phishing, precedentemente definiti nell’SP 800-63B come “impersonificazione del verificatore”, sono tentativi da parte di verificatori fraudolenti di ingannare un incauto richiedente per fargli fornire un autenticatore (in genere password) ad un impostore.

Nella SP 800-63B, la resistenza al phishing è definita come “la capacità del protocollo di autenticazione di impedire la divulgazione dei segreti di autenticazione e dei risultati validi dell’autenticatore a un verificatore impostore senza fare affidamento sulla vigilanza del richiedente”.

In altre parole, la resistenza al phishing sussiste nel caso in cui l’errore umano non può essere determinante.

Il modo in cui il richiedente viene indirizzato al verificatore impostore non è rilevante. Ad esempio, indipendentemente dal fatto che l’attore sia stato indirizzato al verificatore tramite l’ottimizzazione dei motori di ricerca o che sia stato sollecitato tramite e-mail, è considerato un attacco di phishing.

Gli algoritmi crittografici approvati DEVONO essere utilizzati per stabilire la resistenza al phishing, ove necessario. Le chiavi utilizzate a questo scopo DEVONO fornire almeno la forza di sicurezza minima specificata nell’ultima revisione di SP800-131A Rev.2 – Transitioning the Use of Cryptographic Algorithms and Key Lengths (112 bit alla data di questa pubblicazione).

La resistenza al phishing richiede un’autenticazione crittografica a uno o più fattori.

Gli autenticatori che prevedono l’inserimento manuale di un output dell’autenticatore (ad esempio, gli autenticatori out-of-band e OTP) non sono resistenti al phishing perché l’inserimento manuale non lega l’output dell’autenticatore alla sessione specifica da autenticare.

Ad esempio, un verificatore impostore potrebbe trasmettere l’output di un autenticatore al verificatore ed eseguire l’autenticazione con successo.

Si riconoscono due metodi di resistenza al phishing: il channel binding (letteralmente: “Collegamento o associazione del canale”, spiegato nel par.3.2.5.1.) e il verifier name binding (spiegato nel par.3.2.5.2.). Il channel binding è considerato più sicuro del verifier name binding perché non è vulnerabile all’emissione o all’appropriazione indebita dei certificati del verificatore, ma entrambi i metodi soddisfano i requisiti di resistenza al phishing.

Un protocollo di autenticazione con associazione di canale DEVE stabilire un canale protetto autenticato con il verificatore. Il protocollo DEVE quindi legare in modo forte e irreversibile un identificatore di canale negoziato nello stabilire il canale protetto autenticato all’output dell’autenticatore (ad esempio, firmando i due valori insieme utilizzando una chiave privata controllata dal richiedente per la quale la chiave pubblica è nota al verificatore).

Il verificatore DEVE convalidare la firma o altre informazioni utilizzate per dimostrare la resistenza al phishing. Ciò impedisce ad un verificatore impostore, anche uno che ha ottenuto un certificato che rappresenta il verificatore effettivo, di inoltrare con successo tale autenticazione su un canale protetto autenticato diverso.

WebAuthn, che viene utilizzato dagli autenticatori che implementano le specifiche Fast Identity Online 2 (FIDO2), è un esempio di uno standard che fornisce resistenza al phishing attraverso l’associazione del nome del verificatore scegliendo un segreto dell’autenticatore basato sul nome di dominio autenticato del verificatore.

Per maggiori dettagli rimandiamo alle spiegazioni nei citati paragrafi.

Il cap. 6. Threats and Security Considerations e soprattutto il par. 6.1.A uthenticator Threats classificano le minacce agli autenticatori in base agli attacchi ai tipi di fattori di autenticazione che compongono l’autenticatore: “Something you know”, “Something you have” e “Something you are”.

Le minacce ai sistemi di autenticazione multifattore

Le minacce agli autenticatori utilizzate per l’autenticazione digitale sono elencate nella Table 3. Authenticator threats insieme ad alcuni esempi.

Nella parte finale della SP 800-63B troviamo le appendici:

A. Strength of Passwords: illustra i criteri per la lunghezza e la complessità della password, con la nota del NIST a precisare che: “In questa appendice si utilizza il termine “password” per facilitare la discussione. Laddove utilizzato, deve essere interpretato come comprensivo di passphrase, PIN e password.”

Nel paragrafo A.2.Length si ribadisce che la lunghezza della password è un fattore primario nella caratterizzazione della forza della password. Le password che sono troppo corte rendono fattibili gli attacchi di forza bruta e gli attacchi del dizionario.

La lunghezza minima della password richiesta dipende dal modello di minaccia affrontato.

Gli attacchi online in cui l’attaccante tenta di accedere indovinando la password possono essere mitigati limitando il tasso di tentativi di accesso consentito.

Gli attacchi offline sono possibili quando l’attaccante ottiene una o più password con hash attraverso una violazione del database (contenente gli hash delle password).

Abbiamo spiegato in questo articolo quali sono le tecniche di cracking delle password.

La capacità dell’attaccante di ottenere il cracking delle password di uno o più utenti dipende da come viene memorizzata la password. Comunemente, le password vengono salate con un valore pseudocasuale che modifica il calcolo dell’hash, preferibilmente utilizzando un algoritmo computazionalmente costoso.

Anche con tali misure, l’attuale capacità degli aggressori di calcolare molti miliardi di hash al secondo in un ambiente offline che non è soggetto a limitazione della velocità richiede che le password siano ordini di grandezza più complessi di quelle che dovrebbero resistere solo agli attacchi online.

Gli utenti dovrebbero essere incoraggiati a creare le loro password finché vogliono entro limiti ragionevoli. Poiché la dimensione di una password con hash è indipendente dalla sua lunghezza, non c’è motivo di vietare l’uso di password lunghe (o passphrase) se l’utente lo desidera.

Tuttavia, le password estremamente lunghe potrebbero richiedere un tempo di elaborazione eccessivo per l’hash, quindi è ragionevole avere un certo limite.

Nel paragrafo A.3.Complexity è scritto che poiché le scelte delle password degli utenti sono spesso prevedibili, è probabile che gli aggressori indovinino password che in precedenza si sono dimostrate efficaci. Questi includono parole del dizionario e password di violazioni precedenti, come “Password1!”.

Per questo motivo, le password scelte dagli utenti dovrebbero essere confrontate con una lista di password inaccettabili. Questo elenco dovrebbe includere password da precedenti elenchi di data breach, parole del dizionario utilizzate come password e parole specifiche (ad esempio, il nome del servizio stesso) che è probabile che gli utenti scelgano.

B. Syncable Authenticators: si tratta degli Autenticatori sincronizzabili. La possibilità di “sincronizzare” gli autenticatori – in particolare di copiare (cioè clonare) i loro segreti di autenticazione nel cloud e quindi ad altri autenticatori – è uno sviluppo relativamente nuovo nel campo dell’autenticazione. Questa appendice fornisce ulteriori linee guida sull’uso degli autenticatori sincronizzabili.

Infine, nelle appendici C.List of Symbols, Abbreviations, and Acronyms e D.Glossary sono riportati: Elenco dei simboli, abbreviazioni e acronimi ed il glossario (gli stessi presenti negli altri volumi della SP 800-63B).

Il volume SP 800-63C-4 si concentra sulle federazioni di identità.

La Federazione consente a un determinato fornitore di servizi di credenziali di fornire attributi di autenticazione e (facoltativamente) attributi di abbonati a un certo numero di parti di affidamento amministrate separatamente.

La federazione è il processo di autenticazione di un abbonato a una parte affidata (RP: relying party) senza che l’RP verifichi direttamente gli autenticatori dell’abbonato. Un identity provider (IdP) rende disponibile all’RP l’account dell’abbonato definito in SP800-63A attraverso un protocollo di federazione.

L’IdP invia un’asserzione attivata da un evento di autenticazione dell’abbonato all’RP.

Il processo di federazione consente all’abbonato di ottenere servizi da più RP senza la necessità di detenere o mantenere autenticatori separati in ogni RP. Questo processo è talvolta noto come single sign-on (SSO).

Il processo di federazione è anche generalmente l’approccio preferito all’autenticazione quando l’RP e l’account dell’abbonato non sono amministrati insieme in un dominio di sicurezza comune, in quanto elimina la necessità per l’RP di emettere un autenticatore aggiuntivo per l’abbonato da gestire.

Conclusione

La SP 800-63-4 rappresenta un documento fondamentale: come sempre dal NIST arrivano linee guida e best practices estremamente utili, oltre che autorevoli.

Si tratti di un corpo di documenti, in quattro volumi, molto ampio e complesso, ma che vale la pena conoscere per una corretta gestione delle password e – più in generale – dei sistemi di autenticazione sicura.

Soprattutto, in questa Revisione 4, sono state aggiornate le linee guida alla luce di come si sono evolute le tecniche degli attaccanti e degli strumenti di autenticazione che sono stati creati in questi ultimi anni, quali FIDO2 e Passkeys.