Per garantire la sicurezza delle password è un errore imporre all’utente la modifica periodica e di seguire specifiche regole di scrittura (del tipo “almeno una maiuscola e un numero”). Lo dice l’ultima versione delle linee guida del Nist, ma le aziende (e persino le PA) italiane ancora ignorano queste utili raccomandazioni.
Ed è un problema, perché il NIST fa scuola in questa materia. Il National Institute of Standards and Technology) è un’agenzia del governo degli Stati Uniti d’America che si occupa della gestione delle tecnologie e fa parte del DoC, Department of Commerce (Ministero del Commercio).
Nato nel 1901, il NIST ha come compito istituzionale quello di sviluppare standard tecnologici. In particolare, pubblica i Federal Information Processing Standard (FIPS), che definiscono gli standard obbligatori del governo statunitense.
Ovviamente gli standard definiti dal NIST non sono cogenti in Europa, tuttavia per la loro autorevolezza sono considerati un punto di riferimento a livello mondiale.
Lo sono, per esempio, tutte le pubblicazioni FIPS che definiscono gli standard di crittografia DES (Data Encryption Standard) e l’AES (Advanced Encryption Standard), quest’ultimo regolato dalla FIPS PUB 197, e quelle che riguardano gli algoritmi di Hash: FIPS PUB 180-4 per i Secure Hash Standard (SHS) e la più recente FIPS PUB 202 che ha stabilito lo standard SHA-3. Un altro documento molto importante è il FIPS PUB 140-2, che definisce i moduli crittografici.
Indice degli argomenti
Sicurezza delle password: le regole del NIST
Le nuove regole per le password sono nella serie NIST SP (Standard 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.
La regola, divenuta “universale”, di obbligare gli utenti a cambiare le proprie password ogni 3-6 mesi nasce proprio nel 2003 dal NIST SP 800-63. Appendix A, un documento di otto pagine redatto da William Burr. Tra i consigli c’era quello di creare password con tutti i tipi caratteri (numeri, lettere minuscole e maiuscole, simboli) e di cambiarle spesso. Considerata l’autorevolezza del NIST, il manuale venne adottato in tutto il mondo e le sue regole per creare password sicure sono rapidamente diventate uno standard.
Ma nel 2017 il NIST ha rivisto le proprie linee guida sulla gestione delle credenziali, rimuovendo la richiesta di cambio password periodico e aggiornando i requisiti di complessità. Questo è accaduto con la pubblicazione, a giugno 2017 dell’aggiornamento NIST SP 800-63 “Digital Identity Guidelines”.
Negli stessi giorni, Bill Burr ha rilasciato un’intervista al Wall Street Journal dal titolo: The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d!, nella quale in sostanza dichiarava che le regole da lui indicate nel 2003 erano sbagliate o quantomeno superate. Burr consigliava – quattordici anni fa – di utilizzare maiuscole e minuscole, caratteri speciali e almeno un numero. Il risultato poteva essere una password come “P@ssW0rd1” Anche se questa potrebbe sembrare sicura, in realtà è da considerare – oggi – una pessima password. Dal 2003 le potenze di calcolo sono aumentate, così come sono molto più efficaci i software di password cracking di cui dispongono ora gli attaccanti.
Come abbiamo spiegato in un altro articolo, la maggior parte delle persone tende ad usare sempre le stesse tecniche di creazione delle password. È noto – per esempio – che la parola “password” viene modificata – abitualmente e con scarsa fantasia – in: P@ssword, PASSWORD, passw0rd, P@$$w0rd e via dicendo.
Questo rappresenta un punto debole che i criminal hacker conoscono. E che sfruttano con algoritmi di password cracking che tengono specificamente conto delle cattive abitudini degli utenti.
Nuove regole per la sicurezza delle password
La pubblicazione NIST SP 800-63 è costituita da 4 documenti: 800-63-3, 800-63A, 800-63B e 800-63C, disponibili sul sito Internet del NIST stesso.
Quello che riporta le linee guida più utili sull’uso pratico delle password è il NIST SP 800-63B “Digital Identity Guidelines – Authentication and Lifecycle Management”.
Il cambio di orientamento che troviamo in questo aggiornamento è notevole: nel cap.5.1.1.2 “Memorized Secret Verifiers”, alla pagina 14 del documento citato, leggiamo che: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator”.
Quindi, obbligare arbitrariamente le persone a cambiare periodicamente le password (definite “memorized secrets”) 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 correlate 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.
Anche perché le password, quando rubate, vengono sfruttate (“exploited”) in tempi brevi: i cyber criminali usano quasi sempre le credenziali delle loro vittime non appena le compromettono.
La scadenza periodica della password è quindi una difesa solo contro la probabilità che una password (o il suo hash) venga rubata durante il suo intervallo di validità e venga utilizzata da un attaccante. Se una password non viene mai compromessa, non c’è bisogno di cambiarla. E se si ha la prova – o il sospetto – che una password sia stata rubata, è opportuno che si agisca immediatamente piuttosto che aspettarne la scadenza per risolvere il problema.
Oggi, quindi, le linee guida più moderne suggeriscono di non obbligare l’utente a modificare frequentemente le password: tra i primi ad aver abbracciato questa impostazione è stato il National Cyber Security Centre (NCSC) della Gran Bretagna che ha aggiornato in tal senso la propria guida: “Password Guidance: Simplifying Your Approach”.
Anche Microsoft ha rinnovato la sua “Microsoft Password Guidance”, abbandonando la policy di scadenza delle password. Lo possiamo vedere nel documento rilasciato a maggio 2019 “Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903”.
Secondo quanto scritto in tale documento, Microsoft non raccomanderà più una policy che imponga agli utenti di cambiare periodicamente le loro password. E lo motiva con le gli stessi argomenti usati dal NIST: “Quando gli esseri umani sono costretti a cambiare le loro password, troppo spesso fanno una piccola e prevedibile alterazione delle password esistenti e/o dimenticano le nuove password (anche questo è un problema che ben conoscono i responsabili IT delle aziende, n.d.a.).
Le recenti ricerche scientifiche mettono in discussione il valore di molte pratiche di sicurezza delle password, come le policy di scadenza delle password, e indicano invece alternative migliori, come l’applicazione di blacklist di password vietate e l’autenticazione a più fattori”.
Purtroppo, queste regole non sono state invece recepite dalla grande maggioranza delle aziende e dei siti – soprattutto quelli italiani, compresi i siti bancari – che continuano ad imporre il cambio periodico della password.
Le altre indicazioni del NIST
Nei paragrafi successivi della SP 800-63B vengono indicate altre utili linee guida, improntate al buon senso ed alla praticità d’uso.
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 dovrebbero essere imposte “regole di composizione”, come quelle che richiedono, per esempio, “un numero ed un carattere speciale”.
È noto, infatti che in questi casi il pattern statisticamente più utilizzato dagli utenti è: maiuscola all’inizio, numeri e caratteri speciali in fondo. Questo serve solo a dare indicazioni all’attaccante che potrà limitare il numero di tentativi, concentrando l’attacco brute force sulle password più probabilmente usate dagli utenti.
Anche l’imposizione delle famigerate domande di sicurezza è deprecata dal NIST, che invita a non richiederle (rif. cap. 5.1.1.2 Memorized Secret Verifiers). Tali domande (dette “hint”, suggerimento) 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.
Un’altra utile indicazione del NIST è: “I verificatori dovrebbero consentire ai richiedenti di utilizzare la funzionalità di “incolla” quando si inserisce una password”.
Questo facilita anche l’uso dei gestori di password (i password manager), che sono ampiamente consigliati e che aumentano la probabilità che gli utenti scelgano password più forti.
E inoltre: “Per aiutare il richiedente ad inserire con successo un segreto memorizzato (la password), il verificatore dovrebbe offrire la possibilità di visualizzare il segreto – piuttosto che una serie di punti o asterischi – fino al suo inserimento”.
Queste 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.
Ovviamente è anche consigliata l’autenticazione a due fattori, per la quale vengono esaminate le varie modalità disponibili.
Qui, al cap.5.1.3.3 vengono evidenziati i rischi dell’utilizzo della linea telefonica per ricevere il secondo fattore OTP (one time password): una telefonata o un SMS con il codice OTP potrebbero essere dirottati dall’attaccante se questi riesce a realizzare una SIM swap (la clonazione della SIM, una truffa che oggi si sta diffondendo in modo preoccupante).
Meglio quindi utilizzare un “Multi-Factor OTP Device”, come spiegato al cap. 5.1.5: potrebbe trattarsi anche di uno smartphone (“una cosa che hai”), che attraverso un’applicazione apposita genere un codice OTP “time-based”(quindi con una durata molto breve e generato da un algoritmo definito). Di solito si tratta di un codice numerico a 6 cifre.
Per maggior sicurezza – e nella logica dell’autenticazione multi-fattore – lo smartphone deve essere preventivamente attivato da “qualcosa che sai” (una password di sblocco) oppure da “qualcosa che sei” (l’impronta digitale, la faccia ecc.).
Quest’ultimo non è un passaggio da sottovalutare e ci fa capire perché, con l’entrata in vigore della Direttiva (UE) 2015/2366 nota come PSD2 (recepita dall’Italia con il D.lgs. 15 dicembre 2017, n. 218), non sono più ammessi i token hardware (quelle chiavette in plastica che generavano un codice a 6 numeri) per l’autenticazione nei siti bancari: erano dispositivi non sicuri, perché potevano essere attivati senza alcun codice di sicurezza. Quindi in caso di furto o smarrimento, chiunque avrebbe potuto utilizzarli.
La SP 800-63B riporta molte altre utili linee guida, che dovrebbero essere applicate da chi amministra i sistemi IT delle aziende e anche da chi realizza servizi web: quelli che il NIST definisce “Verifiers” e che per primi hanno il dovere di implementare adeguate misure di sicurezza per le procedure di autenticazione.
In particolare, si evidenzia la necessità che i Verifiers salvino le password sotto forma di hash (vedere articolo “Attacco alle password: tecniche di cracking e consigli per metterle al sicuro”), utilizzando inoltre il “salt” (sale). Un salt è un numero generato in modo casuale che viene aggiunto in coda al testo della password. Da tale stringa composta, viene poi calcolata la chiave derivata (hash).
In questo modo si rendono molto più onerosi gli attacchi “a dizionario” e quelli “brute force”.
Lo scopo del salt è infatti quello di moltiplicare il numero di combinazioni hash possibili a fronte di ciascuna password.
Per una data password (che se priva del salt avrebbe un unico hash come risultato), il numero di possibili combinazioni diventa invece pari a: 2sLen dove sLen è la lunghezza del salt in bit.
Per esempio, con un salt di 32 bit il numero di hash possibili si moltiplica di un fattore pari a 232 = 4.294.967.296, ove il valore di 32 bit è la lunghezza minima consigliato dalla SP 800-63B (cap.5.1.1.2).
In abbinamento ad hash e salt, la medesima pubblicazione consiglia (per i Verifiers che conservano le password ed eseguono il processo di autenticazione dell’utente) di implementare anche algoritmi di derivazione della chiave KDF (Key Derivation Function).
Uno dei più utilizzati è il PBKDF2 (Password-Based Key Derivation Function 2) la cui specifica è definita nella RFC 2898, poi aggiornata nel 2017 con la RFC 8018.
L’algoritmo prevede l’utilizzo di una password e di un salt, a cui si aggiunge un “iteration count” che specifica il numero di volte in cui una funzione hash deve essere ripetuta prima di restituire la chiave derivata.
Ovviamente, più volte la funzione PBKDF2 viene iterata, più tempo ci vuole per calcolare l’hash della password.
Lo scopo è quella di rallentare gli attacchi a dizionario o di forza bruta alle password aumentando il tempo necessario per testare ogni password.
Un “iteration count” elevato renderà l’attacco computazionalmente più oneroso, fino a fare diventare il crack delle password praticamente impossibile (in crittografia, con il termine “impossibile” si intende un processo non realizzabile con gli strumenti computazionali disponibili).
Il NIST raccomanda un valore di “iteration count” pari almeno a 10.000 iterazioni.
Agli algoritmi di derivazione della chiave PBKDF il NIST dedica un documento specifico: SP 800-132 “Recommendation for Password-Based Key Derivation” a cui rimandiamo per ulteriori approfondimenti.
