Conservazione delle password nei Domini Microsoft AD-DS
Introduzione
L’Agenzia per la Cybersicurezza Nazionale in accordo con il
Garante per la protezione dei dati personali hanno redatto delle specifiche
guide relative alla conservazione delle password da adottare in ogni
organizzazione allo scopo di aumentare il livello di sicurezza.
Articolo dell’ACN: Conservazione delle password
Il documento contiene delle raccomandazioni su come
conservare le password. Essendo delle indicazioni caldamente raccomandate
queste potranno o dovranno essere adottate, a seconda dei singoli contesti con
specifici adattamenti.
L’obiettivo del documento è quello di alzare il livello di sicurezza adottati da fornitori di servizi e software house essendo molti “data breach” dovuti troppo spesso a scarse modalità di protezioni delle password.
Gli elementi principali delle linee guida
Nelle linee guide vengono presentati alcuni elementi, andiamoli a vedere dal punto di vista informatico e pratico.
Password Hashing
Sviluppare un prodotto che richiede delle password per l’autenticazione degli utenti significa che bisogna implementare un metodo di verifica di queste password.
Però salvare in chiaro le password nel database porta a importati rischi di sicurezza se il DB viene violato. Anche se l’applicazione che si utilizza non è particolarmente sensibile per la sicurezza (non manipola dati sensibili) dato che la maggior parte degli utenti utilizza le stesse password in molte applicazioni, un eventuale attaccante potrebbe trovare una password che viene utilizzata pure in contesti piu sensibili, come l’account di sistemi bancari.
Quindi, conservare in modo sicuro le password è un punto essenziale per mitigare questi rischi.
L’hashing delle password è una strategia per assicurare che le password vengano conservate in modo sicuro.
Le basi del Password Hashing
L’hashing delle password è l’applicazione di un algoritmo che converte una password in un testo cifrato, cioè una versione nascosta e irreversibile di essa, con l’intento di bloccare la minaccia di violazione della password. In particolare, una stringa di caratteri (la password) è trasformata in una stringa completamente differente usando una funzione matematica di hashing. Quando una stringa (la password) è stata “tritata” non c’è nessun modo di invertire il processo (in un tempo accettabile). Ogni volta che un utente si autentica, la password che inserisce (processata) viene confrontata con la stringa hash salvata.
Un po' di chiarimenti
Prendiamo un esempio pratico esposto con termini non prettamente tecnici.
Consideriamo di avere tre utenti Aldo, Giovanni e Giacomo che registrano tre account nella piattaforma informatica (applicativo web, Dominio, etc); alla fine della registrazione si avranno username e password che useranno per autenticarsi. Il sistema dovrà memorizzare la password immessa dall’utente.
Il modo più semplice è quello di salvarle in chiaro (senza nessuna modifica) in un DB, che vuol dire avere un legame diretto tra nome utente e password in una forma leggibile.
Anche se il DB, dove sono state salvate le password, fosse messo in sicurezza da un sistema autenticazione per gli utenti che devono accedervi questo metodo di salvataggio è altamente vulnerabile. Se un attaccante riesce ad accedere al server (o anche un impiegato malevolo con diritti di accesso), avrà le password di tutti gli utenti in un testo leggibilissimo che potrà utilizzare non solo nei sistemi aziendali ma pure in altre piattaforme.
Differenti metodi di conservazione sicura delle password
La modifica migliore che si può pensare di fare potrebbe essere quella di crittografare le password salvate nel db, quando un utente si autentica nella piattaforma si può decriptare la password salvata e confrontarla con la password inserita dall’utente. Ma c’è un intoppo: il processo di criptazione è una procedura a due direzioni, cioè la chiave di criptaggio può essere usata per decriptare la stringa (la password) per ottenerne la relativa stringa in chiaro.
Un attaccante che riesce ad infiltrarsi nel sistema, può avere accesso non solo al DB ma pure ad altre parti del sistema e riuscire a scoprire la chiave di criptaggio che si utilizza; senza considerare la possibilità, gia accennata, di un impiegato con privilegi di accesso DB delle chiave.
A differenza della crittografia, l’hashing è un processo ad una sola direzione.
Nel processare la password, attraverso un algoritmo di hashing ad una sola via, si ottiene una stringa di testo che non può essere decodificata o riportata al testo originale in chiaro (in un tempo di calcolo umanamente accettabile).
Quando un utente crea una password l’applicazione la processa con un algoritmo di hashing e salva il valore della stringa casuale che ne ottiene nel DB (a differenza del salvare il testo in chiaro o il valore crittografato); ogni volta che l’utente si autentica, l’applicazione esegue la stessa funzione di hash sulla stringa immessa dall’utente e ne confronta la stringa risultante con la stringa che ha salvata nel DB.
La caratteristica che rende questa procedura di salvataggio della password altamente sicura è la non fattibilità di invertire la funziona di hashing, e quindi elimina il punto piu suscettibile di attacco.
Comunque questo non vuol dire che è impossibile trovare la password. Se si riesce ad avere accesso al DB con le password hash salvate alcuni tipi di attacchi come i “Brute Force”, “Dictionary Attack”, “Rainbow Table” possono aiutare a trovare la password (in chiaro in un tempo accettabile).
In particolare, il Rainbow Table ha una buona efficienza computazionale (anche se molto vorace di risorse) utile a questo scopo.
In questo tipo di attacco viene creata una tabella che memorizza una serie di hash concatenati per le maggiori password comunemente usate. L’attaccante, quindi, può utilizzare la tabella come ricerca per verificare se l’hash della password del database compromesso esiste nella tabella e quindi tracciare la catena hash all’indietro per identificare la password originale in chiaro
Come si può vedere eseguire l’hashing della password da solo non è completamente sicuro.
Per rendere una procedura di Hashing ancora piu sicura si può usare la tecnica del Salt (Sale) o quella del Pepper (Pepe), o anche entrambi
Il Salt è una sequenza di caratteri casuali aggiuntivi che si combinano con la password originale, che poi passerà attraverso l’algoritmo di hash per creare il valore della password cifrata salvato nel db.
Esempio:
password [lamiapassword] + salt [3sdvv46] -> hashing -> [21b837e737f987367e98b7868a676b]
Anche se aggiungere il Salt aumenta di un ulteriore step la sicurezza delle password hashing, ha comunque delle limitazioni. Per esempio, il salt dell’esempio è messo dopo ogni password, questo crea una tendenza che è facile per un attaccante identificare, oltre a questo molte organizzazioni tenderanno ad applicare lo stesso valore di Salt per tutte le password.
Il Pepper è un valore segreto che, come per il salt, viene aggiunto alla password prima della procedura di hashing. A differenza del salt, però, il pepper di solito è inserito all’interno del codice del sistema che esegue l’hashing della password, il che rende ancora più difficile la decifratura.
Principali algoritmi di hashing.
Vediamo alcuni moderni algoritmi di password hashing:
- Bcrypt: è un algoritmo di hashing di password molto usato. Si basa sulla cifratura Blowfish, in corpora un salt e un fattore di complessità regolabile per rallentare il processo di hashing; in questo modo gli attacchi di forza bruta vengono resi più dispendiosi a livello di tempo. È stato progettato per resistere agli attacchi di tipo side-channel ed è considerato sicuro per l’archiviazione delle password.
- Scrypt: è un algoritmo di hashing di password che richiede una significativa quantità di memoria per il calcolo dell’hash, rendendo quindi più difficile per gli attaccanti di eseguire degli attacchi paralleli utilizzando particolari hardware. Offre pure un fattore di complessità e la tecnica del salt. È stato progettato specificamente per proteggere dagli attacchi basati su hardware, come quelli con GPU e ASIC.
- Argon2: è un algoritmo di hashing di password moderno che richiede molta memoria. Offre piu fattori di complessità, sia per il tempo (di calcolo) che per la memoria, dando così la possibilità di equilibrare tra sicurezza e prestazioni; supporta pure la tecnica del Salt. Ha tre diversi varianti: Argon2i (ottimizzato per gli attacchi side-channel), Argon2d (ottimizzato per gli attacchi di tipo Time-Memory Trade-Off ), Argon2id (un ibrido tra i due precedenti).
- PBKDF2 (Password-Based Key Derivation Function 2): è un algoritmo di hashing di password largamente usato che applica in modo iterativo una funzione pseudocasuale, come la HMAC , alla password immessa e al salt. Offre il fattore di complessità regolabile, aumentando il numero di iterazioni per rendere il processo di hashing più lento e più resistente agli attacchi. Non richiede molta memoria e quindi potrebbe essere più suscettibile agli attacchi basati su hardware rispetto ai due precedenti.
In AD-DS
La password inserita dall’utente viene trasformata in hash (hashNT) che viene archiviata in memoria da windows con una procedura che è gestita dal processo di sistema LSASS (Local Security Authority Subsystem Service), Microsoft Defender contribuisce a ridurre la superficie di attacco evitando l’estrazione dei dati dalla memoria locale.
Se un utente è un account locale, il relativo hashNT viene confrontato con quello archiviato localmente nel database SAM (Security Accounts Manager); se entrambe le stringe hash corrispondono, l’autenticazione ha esito positivo e all’utente viene accordato l’accesso richiesto.
Se un utente utilizza un account Active Directory, il relativo hashNT viene utilizzato nell’autenticazione Kerberos avvalendosi del controller di dominio. Al termine dell’autenticazione con l’Active Directory, viene emesso un Ticket Granting Ticket (TGT) di Kerberos, memorizzato nella cache dei ticket.
Gli hashNT delle password sono vulnerabili quindi si dovrebbe sempre usare l’autenticazione Kerberos quando possibile.
Modalità di archiviazione delle password
Windows rappresenta le password in stringhe UNOCODE di 256 caratteri, ma la “finestra di dialogo” di accesso è limitata a 127 caratteri; quindi, la password più lunga possibile ha 127 caratteri.
Il sistema operativo Windows archivia la password in molti modi diversi a seconda dello scopo.
Password archiviate come OWF
Per l’uso nei domini di Active Directory, la password viene archiviata in due modi diversi per impostazione predefinita:
- LM OWF: incluso in Windows per garantire la compatibilità con le versioni precedenti e con software e hardware che non possono usare algoritmi più recenti.
- NT OWF: la password viene sottoposta a hash utilizzando l’algoritmo MD4 e archiviata. NT OWF viene usato per l’autenticazione da parte dei membri del dominio sia in Windows NT 4.0 che in domini precedenti e nei domini di Active Directory
Ne l’hashNT ne l’hashLM hanno il Salt.
Password archiviate in Active Directory
|
Attributo AD |
Contenuto |
|
Unicode Pwd |
HashNT crittografato |
|
dbcsPwd |
HashLM crittografato |
|
ntPwdHistory |
HashNT crittografati - Cronologia password |
|
lmPwdHistory |
HashLM crittografati - Cronologia password |
|
supplementalCredentials |
Chiavi Kerberos, WDigest e così via. |
L’archiviazione degli hashLM è disabilitata per impostazione predefinita da Windows Vista e Windows Server 2008.
Archiviando nel file .DIT, l’hashNT è protetto da due livelli di crittografia. In Windows Server 2016/Windows 10 e versioni successive, viene crittografato con DES per garantire la compatibilità con le versioni precedenti e quindi con SNG Bcrypt AES-256. Le versioni precedenti di Windows crittografano gli hashNT usando due livelli di crittografia DES + RC4.
Password archiviate nel SAM locale
Nei membri di dominio e nelle workstation, gli hash delle password degli account utenti locale vengono archiviati in un database SAM (Security Account Manager) locale che si trova nel Registro di sistema e vengono crittografati usando gli stessi algoritmi di crittografia e hash di Active Directory. Le password nell’attributo supplementalCredentials per gli account utenti locali vengono archiviate anche nel database SAM locale a partire da Windows Server 2016.
Credenziali memorizzate nella cache
Windows archivia anche un verificatore di password nei membri del dominio quando un utente di dominio accede a tale membro di dominio; questo verificatore può essere usato per l’autenticazione dell’utente se il computer non è in grado di accedere al controller di dominio. Il verificatore delle password viene comunemente chiamato “credenziale memorizzata nella cache” e viene calcolato prendendo l’hashNT, concatenando il nome utente e quindi eseguendo l’hashing del risultato usando la funzione hash MD4.
Funzionamento delle password di windows
In Windows, come in molti altri sistemi operativi, l’autenticazione dell’identità di un utente viene fatta attraverso l’uso di una passphrase o una password.
È consigliabile usare una autenticazione a più fattori sicura come ad esempio Smart Card, FIDO, Windows Hello. Però l’autenticazione attraverso una password è ancora necessaria in diverse situazioni.
Le impostazioni dei criteri password controllano la complessità e la durata delle password, i criteri di password influiscono sulle password di Windows e non obbligatoriamente sulle password delle funzioni.
I criteri di password controllano pure la capacità degli utenti di modificare le password.
Ad esempio, a seconda dei criteri password gestiti dall’amministratore di sistema o dall’amministratore di dominio si controlla la capacità degli utenti di modificare le password; funzionalità tipo Windows Vault, Bitlocker o Encrypting File System consentono agli utenti di modificare le password specifiche di tali funzionalità.
Modalità di utilizzo delle password di Windows
Quando un utente accede la password che immette viene convertita in entrambi i tipi di funzioni unidirezionali e mantenuta in memoria dal processo LSASS (Local Security Subsystem Service)
Se l’utente usa l’account locale NT OWF viene confrontato con l’hashNT archiviato in locale e, se corrispondono, l’utente viene autenticato ed accede.
Se l’utente effettua l’autenticazione in un dominio di AD usando un nome host per accedere a una risorsa, l’hashNT viene usato in un accesso Kerberos al centro distribuzione chiavi (KDC) che solitamente è il controller di dominio.
- Autenticazione in un dominio di livello Windows NT o versioni precedenti
- Accesso a risorse di un membro di dominio AD tramite indirizzo IP invece che nome host
- Accesso a risorse di un computer che non è membro di un dominio AD
- Accesso a risorse di un computer membro di un dominio AD che non è attendibile.
- Accesso a qualsiasi risorsa su un computer in esecuzione che non supporta Kerberos
In questi casi l’autenticazione usa due protocolli diversi, LAN Manager e NTLM. Il client richiede una verifica al server di autenticazione, dopo che riceve la richiesta di verifica il client calcola la risposta. Operazione che viene eseguita riempiendo prima i due hash della password con valori NULL a 168bit, questi 168bit di ogni hash vengono quindi divisi in 3 chiavi DES a 56bit. Le 6 chiavi DES vengono quindi usate per crittografare la richiesta di verifica.
Le tre stringhe cifrate prodotte tramite l’hashLM vengono concatenate e diventano la risposta di LAN Manager.
Le tre stringhe cifrate prodotte tramite l’hashNT vengono concatenate e diventano la risposta NTLM.
Le funzioni usate per calcolare la risposta possono essere modificate delle group policy.
Le nuove versioni dei due protocolli sono LMv2 e NTLMv2, solo NTLMv2 però viene usata. Entrambi i protocolli usano l’hashNT per calcolare le risposte e usano una richiesta lato client al posto o anche in aggiunta alla richiesta lato server. Inoltre se l’opzione LM Compatibility Level è impostata alla prima opzione o superiore la risposta NTLM viene contrassegnata con un timestamp per evitare “replay attack” .
I dispositivi client che non supportano l'autenticazione NTLMv2 non possono eseguire l'autenticazione nel dominio e accedere alle risorse del dominio utilizzando LM e NTLM.
Passphrases in Windows
Una passphrase è una forma differente di password basata su token, in cui i token sono parole anziché simboli di un set di caratteri. Un esempio di passphrase è una frase che contiene caratteri speciali, numeri, lettere sia maiuscole che minuscole. Le differenze principali tra questa e la password sono:
- Una passphrase solitamente ha degli spazi (mentre le password no)
- Una passphrase è molto più lunga, solitamente di una parola, e più importante è più lunga di qualsiasi stringa casuale di lettere che una persona normale può ricordare
Come abbiamo visto le password vengono salvato nell’hashLM e nell’hashNT, e l’hashLM è il più debole dei due.
- Usare password o passphrase più lunghe di 14 caratteri: questo perché, spiegato in modo semplice, fino a 14 caratteri Windows salva la password nei due hashLM e hashNT, da 15 in su spezza la password in due stringhe e non la salva più in un hashLM perché ottiene due valori hash
- Usare l’impostazione Network security: Do not store LAN Manager hash value on next password change. Usandola globalmente viene disabilito il salvataggio in hashLM per tutti gli account.
Criteri granulari per le password tramite AD-DS
Da Windows server 2008 è possibile usare dei criteri granulari per le password in modo da avere più criteri password in un unico dominio e applicare restrizioni diverse (per password e blocco di account) a seconda del gruppo utente di dominio
Un esempio. Per aumentare la sicurezza degli account con privilegi si possono applicare impostazioni piu rigide per gli account con privilegi elevati e impostazioni meno rigide per gli account degli altri utenti.
- Password Settings Container
- Password Settings
Commenti