Uso corretto delle password: i consigli NIST per la sicurezza delle identità digitali

Con la recente pubblicazione del secondo “public draft” della SP 800-63 Digital Identity Guidelines, il NIST ha profondamente aggiornato le linee guida più autorevoli per l’uso delle password e della gestione delle identità digitali.

Questa nuova revisione intende rispondere ai cambiamenti del panorama digitale emersi dall’ultima revisione principale di questa linea guida, pubblicata nel 2017, con una particolare attenzione per le implicazioni reali dei rischi online.

Le linee guida presentano i requisiti tecnici e di processo per soddisfare i livelli di garanzia della gestione dell’identità digitale per la verifica dell’identità, l’autenticazione e la federazione, compresi i requisiti per la sicurezza e la privacy, nonché le considerazioni per promuovere l’usabilità delle soluzioni e delle tecnologie di identità digitale.

Linee guida NIST sull’uso delle password: la storia

Il nuovo documento, ancora in fase di bozza, va ad aggiornare la Special Publication NIST SP 800-63, che era stata pubblicata nel 2017 e di cui abbiamo parlato in un precedente articolo.

Come per la precedente edizione, anche in questo caso il public draft è costituito da quattro documenti, indicati come revisione numero 4:

1. SP 800-63-4 Digital Identity Guidelines;
2. SP 800-63A Identity Proofing & Enrollment;
3. SP 800-63B Authentication & Authenticator Management;
4. SP 800-63C Federation & Assertions.

Il “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.

Questa prima bozza ha ricevuto – secondo la prassi del NIST – molti commenti e feedback da parte di enti e individui interessati.

Come dichiara il NIST, questi commenti sono serviti a “migliorare le Linee guida per l’identità digitale in modo da sostenere gli obiettivi critici del NIST di fornire processi e requisiti fondamentali di gestione del rischio che consentano l’implementazione di sistemi di identità sicuri, privati, equi e accessibili”.

Sulla base dei commenti e delle osservazioni raccolte, ora il NIST ha pubblicato questa seconda bozza che, appunto, costituisce la quarta revisione dopo le seguenti:

1. 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);
2. SP 800-63-1 Electronic Authentication Guideline: pubblicata nel dicembre 2011;
3. 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;
4. 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 “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.
5. SP 800-63-4 Digital Identity Guidelines: il secondo “public draft” è stato pubblicato il 21 agosto 2024. NIST richiedeva che tutti i commenti a questo documento fossero inviati entro le 23:59 (ora della costa orientale statunitense) del 7 ottobre 2024. Non viene specificato quando sarà prevista la pubblicazione definitiva e ufficiale della SP 800-63-4.

Uso corretto delle password: dettagli delle linee guida NIST

Come abbiamo detto, la SP 800-63-4 è 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.

1. La sezione 1 fornisce un’introduzione al documento.
2. La sezione 2 descrive un modello generale di identità digitale.
3. 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 SP800-53 Rev.5 Security and Privacy Controls for Information Systems and Organizations pubblicata nel settembre 2020 e di cui abbiamo parlato in un precedente articolo.

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

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

L’Appendice B contiene un glossario di termini utilizzati in questo documento.

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

Molto interessante nella SP 800-63-4 il punto 1.4 Notations, dove sono spiegate con grande chiarezza le convenzioni tipografiche utilizzate nel testo:

1. I termini specifici in MAIUSCOLO rappresentano requisiti normativi. Quando gli stessi termini non sono in MAIUSCOLO, il termine non rappresenta un requisito normativo.
2. 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.
3. I termini “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.
4. I termini “POSSIBILE” (“MAY”) e “NON NECESSARIO” (NEED NOT”) indicano una linea d’azione ammissibile entro i limiti indicati nella linea guida.
5. 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.

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 per quanto riguarda la creazione e il mantenimento degli account degli abbonati e il collegamento degli autenticatori emessi dal CSP (Credential Service Provider) o forniti dall’abbonato 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).

Authentication & Authenticator Management: punti cardine

Come anticipato, SP 800-63B è tra i quattro volumi delle linee guida quello che contiene le nozioni e i consigli più pratici e utili per l’utilizzo delle password e dell’autenticazione forte (MFA).

Tratta l’autenticazione dei soggetti che interagiscono con i sistemi informativi attraverso le reti per stabilire che un determinato richiedente è un utente che è stato precedentemente autenticato.

Il risultato del processo di autenticazione può essere utilizzato localmente dal sistema che esegue l’autenticazione o può essere rivendicato altrove in un sistema di identità federato.

Fornisce i requisiti ai fornitori di servizi di credenziali (CSP: credential service providers) per l’autenticazione degli utenti remoti a ciascuno dei tre livelli di garanzia dell’autenticazione (AAL):

1. Authentication Assurance Level 1: AAL1 fornisce una sicurezza di base che il richiedente controlli un autenticatore legato all’account dell’abbonato da autenticare. L’AAL1 richiede solo l’autenticazione a fattore singolo utilizzando un’ampia gamma di tecnologie di autenticazione disponibili. Tuttavia, si raccomanda che le applicazioni valutate in AAL1 offrano opzioni di autenticazione a più fattori. Un’autenticazione riuscita richiede che il richiedente dimostri il possesso e il controllo dell’autenticatore.
2. Authentication Assurance Level 2: AAL2 fornisce un’elevata sicurezza che il richiedente controlli uno o più autenticatori legati all’account dell’abbonato da autenticare. È necessario dimostrare il possesso e il controllo di due fattori di autenticazione distinti. Le applicazioni valutate con AAL2 devono offrire un’opzione di autenticazione resistente al phishing.
3. Authentication Assurance Level 3: l’AAL3 fornisce una fiducia molto elevata sul fatto che il richiedente controlli uno o più autenticatori collegati all’account dell’abbonato da autenticare. L’autenticazione AAL3 si basa sulla prova del possesso di una chiave attraverso l’uso di un protocollo crittografico a chiave pubblica. L’autenticazione AAL3 richiede un autenticatore basato su hardware con una chiave privata non esportabile e un autenticatore resistente al phishing (è illustrato alla sezione 3.2.5); lo stesso dispositivo può soddisfare entrambi i requisiti. Per l’autenticazione in AAL3, i richiedenti devono dimostrare il possesso e il controllo di due fattori di autenticazione distinti.

I requisiti per i livelli AAL sono riportati al cap.2.5 Summary of requirements, riportato nella figura sottostante.

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

Nel 3.1.1 Passwords dove 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.

Si specifica che “le password non sono resistenti al phishing”(concetto importante, ma non a tutti noto).

Infatti, come precisato nell’Appendice A Strength of Passwords: “Molti attacchi associati all’uso delle password non sono influenzati dalla complessità e dalla lunghezza delle stesse. Gli attacchi di keystroke logging, phishing e social engineering sono altrettanto efficaci con le password lunghe e complesse che con quelle lunghe e complesse”.

È noto che gli esseri umani hanno una capacità limitata di memorizzare password complesse; quindi, spesso scelgono password che possono essere facilmente indovinate. Per affrontare i problemi di sicurezza che ne derivano, i servizi online hanno introdotto regole per aumentare la complessità delle password. La forma più notevole è quella delle regole di composizione, che richiedono agli utenti di scegliere password costruite utilizzando un mix di tipi di caratteri (ad esempio, almeno una cifra, una lettera maiuscola e un simbolo).

Tuttavia, le analisi dei database di password violate rivelano che il beneficio di tali regole è meno significativo di quanto si pensasse inizialmente e gli impatti sull’usabilità e sulla memorizzazione sono gravi.

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.

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

1. I verificatori e i CSP (credential service providers) devono richiedere che le password abbiano una lunghezza minima di otto caratteri e dovrebbero richiedere che le password abbiano una lunghezza minima di 15 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 [RFC20] 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 punto di codice Unicode deve essere contato come un carattere di segno 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 verificare l’intera password inviata (cioè non troncarla).

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 (RFC 20) 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 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 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).

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

Tali domande (dette “hint”, suggerimento) sono in genere di questo tipo:

1. Il nome del tuo primo animale?
2. 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:

1. password ottenute da precedenti database di violazioni;
2. parole del dizionario;
3. parole specifiche del contesto, come il nome del servizio, il nome utente e i suoi derivati.

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 molti 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.

Nel paragrafo 3.1.4.Single-Factor OTP sono indicate le misure consigliate per l’autenticazione a singolo fattore con OTP (one-time password), mentre 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 da un fattore di attivazione che rappresenta “qualcosa che si conosce” o “qualcosa che si è”.

L’autenticazione crittografica è resistente al phishing se soddisfa i requisiti aggiuntivi di cui al punto 3.2.5.Phishing (Verifier Impersonation) 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”.

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 (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.

Per maggiori dettagli rimandiamo alle spiegazioni nei citati paragrafi.

Il cap. 6.Threats and Security Considerations e soprattutto il par. 6.1.Authenticator 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”.

La classificazione di tali minacce è riportata nella Table 2.Authenticator threats.

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

1. Strength of Passwords: illustra i criteri per la lunghezza e la complessità della password, con la nota del NIST 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.”
2. 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 e D sono riportati: Elenco dei simboli, abbreviazioni e acronimi ed il glossario (gli stessi presenti negli altri volumi della SP 800-63B).

In conclusione

Come sempre, dal NIST arrivano linee guida e best practices estremamente utili, oltre che autorevoli.

Si tratti ancora di una bozza, ma essendo il Second Public Draft e visto il livello di dettaglio, abbiamo motivo di ritenerla ormai definitiva.

Ne abbiamo fatto una presentazione sintetica, tenuto conto delle dimensioni dei quattro volumi. Consigliamo di scaricare i documenti completi, tutti disponibili (gratuitamente e solo in inglese) dalla pagina ufficiale del NIST.