Conservazione password, come usare la crittografia: le linee guida ACN-Garante privacy

Sono state da poco emanate le linee guida riguardanti le funzioni crittografiche da utilizzare per la conservazione delle password, elaborate dall’ACN d’intesa con il Garante per la protezione dei dati personali.

Vediamo quali sono le indicazioni pratiche che devono essere tenute in considerazione dalle organizzazioni al fine di una corretta conservazione delle password.

L’esigenza primaria: la protezione e l’accountability

La necessità di indicare delle linee guida per la conservazione delle password nasce, da un lato, dall’utilizzo massiccio, nel mondo digitale, di sistemi di autenticazione, a uno o più fattori, che molto spesso comprendono l’utilizzo di password, dall’altro, dalla compromissione delle stesse a causa di incidenti informatici e data breach.

La gestione delle password, come sappiamo, rappresenta un aspetto fondamentale della sicurezza informatica e, allo stesso tempo, della protezione dei dati personali, costituendo una tematica trasversale che interessa entrambi gli ambiti.

I gestori dei sistemi e servizi devono, pertanto, prevedere misure tecniche e organizzative efficaci per l’archiviazione, la conservazione e l’utilizzo delle chiavi di accesso, in quell’ottica di accountability indicata dal GDPR.

Gli archivi in cui sono conservate le password, sempre più frequentemente, vengono coinvolti nei data breach, vengono copiati ed esfiltrati e, nella maggior parte dei casi, sono pubblicati online, oppure vengono utilizzati per condurre altri attacchi.

In tale scenario si comprende l’importanza che assume la crittografia, proprio come mezzo di protezione delle passoword, prima e contrasto alla loro diffusione, poi.

Le linee guida licenziate da ACN e Garante per la protezione dei dati personali hanno esattamente questo obiettivo, ossia fornire indicazioni e raccomandazioni sulle funzioni crittografiche attualmente più sicure.

Il password hashing

Il primo elemento da considerare è la necessità di utilizzare sistemi di crittografia per la conservazione delle password e, in aggiunta a questo, l’esigenza di impiegare sistemi crittografici efficaci e che possano diminuire il rischio non solo di attacco, ma anche di decifratura delle password crittografate.

Le linee guida partono dall’introduzione delle tecniche di password hashing, sottolineando, quindi, come non siano compatibili con i principi di sicurezza informatica la memorizzazione e la conservazione di password in chiaro, ossia senza cifratura.

Sarà quindi necessario salvare non la password, ma il relativo digest, ossia una stringa di caratteri che viene calcolata, attraverso una funzione di hash, sulla password che deve essere cifrata. In questo modo un eventuale attaccante potrebbe vedere unicamente i digest, senza, quindi, vedere le password, essendo, i primi, one-way. Ciò significa che, essendo molto complessa l’inversione delle funzioni di hash, è estremamente difficile riuscire ad ottenere le password originali degli utenti.

Ulteriori aspetti di vulnerabilità da considerare

Restano, tuttavia, alcuni aspetti di vulnerabilità che dovranno essere considerati al fine della individuazione delle misure atte alla loro mitigazione.

In particolare eventuali attaccanti potranno procedere in due modi diversi:

• con un attacco di forza bruta: in tal caso viene calcolato l’hash di password casuali fino a trovare una corrispondenza con i digest che sono stati trafugati.
• con un attacco al dizionario: questo tipo di attacco sfrutta il fatto che, solitamente, gli utenti scelgono password banali o comunque parole di senso compiuto, per cui un attaccante potrebbe calcolare l’hash delle password più comuni fino a trovare una corrispondenza all’interno dell’archivio esfiltrato. Si aggiunga, poi, che vengono spesso utilizzate delle rainbow tables, ovvero tabelle precompilate contenenti i digest di un numero elevato di password comuni. Questi digest possono essere direttamente confrontati con quelli nell’archivio, rendendo, di fatto, l’attacco estremamente rapido.

Bisogna considerare, poi, un aspetto fondamentale che riguarda la tipologia di password impiegate dagli utenti: chiunque venga in possesso della lista dei digest potrà individuare le password uguali poiché sarà uguale anche il relativo digest.

I requisiti degli algoritmi di password hashing

Per questa ragione è necessario che gli algoritmi di password hashing abbiano specifici requisiti, ossia:

• abbiano una complessità computazionale tale per cui sia rapido calcolare un singolo digest, ma sia eccessivamente dispendioso calcolarne un numero elevato, così da scoraggiare gli attaccanti a cercare le password degli utenti procedendo per tentativi;
• abbiano una capacità di memoria richiesta tale da saturare la RAM quando molti digest vengono calcolati contemporaneamente.

In altre parole gli algoritmi devono agevolare il calcolo di un solo digest, e, al contrario, ostacolarne il calcolo di un numero elevato, andando in questo ultimo caso a saturare la memoria RAM al fine precipuo di contrastare l’attività illecita di un attaccante.

Le linee guida indicano, poi, una particolare strategia: l’adozione di digest con dimensioni raddoppiate consente, alla crittografia simmetrica, di resistere agli attacchi perpetrati da computer quantistici tramite l’algoritmo di Grover.

Se, come visto, il digest è passibile di un attacco, indipendentemente dalla tipologia dello stesso, è necessario individuare quale sia la misura concreta idonea a mitigare il rischio che le password possano essere identificate.

L’uso di salt e pepper per aumentare la sicurezza

A tal riguardo è possibile, proprio al fine di renderlo meno facilmente “decifrabile”, aggiungere allo stesso un salt, ossia una stringa di bit casuali che viene concatenata alla password prima del calcolo del digest, che poi viene salvata in chiaro insieme al digest creato. Al fine di innalzare ulteriormente il livello di protezione è possibile salvare il salt in un archivio differente da quello contenente i digest.

Ad ogni modo il salt, sebbene sia salvato in chiaro, garantisce protezione per diverse ragioni:

• in un attacco al dizionario, quando l’attaccante calcola il digest di una password, per ogni utente deve concatenare il salt corrispondente, che sarà valido solo per quel singolo utente. In tal modo, il numero di applicazioni della funzione di hash che l’attaccante dovrà effettuare per tentare di individuare gli utenti che utilizzano una determinata password cresce all’aumentare della dimensione dell’archivio delle password degli utenti;
• due utenti che utilizzano la stessa password avranno diverso salt e quindi verranno loro associati due diversi digest. Questo comporta che con un’unica computazione non è possibile individuare il fatto che più utenti utilizzano la medesima password;
• le rainbow table diventano inutilizzabili, poichè anche le password più comuni vengono modificate dal salt e quindi è necessario ricalcolare la tabella aggiungendo tutti i possibili salt per ogni password, rendendo, chiaramente, il processo più dispendioso.

In sostanza il salt non aumenta il livello di sicurezza della conservazione della password di un utente specifico, ma consente di rallentare le capacità offensive di un attaccante sull’intero archivio in modo direttamente proporzionale alla sua dimensione.

In ogni caso per poter risultare efficace, il salt dovrebbe:

• essere generato casualmente per ogni password;
• avere una lunghezza adeguata, altrimenti un attaccante avrebbe comunque la capacità di precalcolare una particolare rainbow table, concatenando tutti i possibili salt alle password più comuni.

Per aggiungere un ulteriore livello di sicurezza a volte viene aggiunto un pepper, ossia una stringa di bit casuale che, al contrario del salt, può essere la stessa per tutte le password nell’archivio, ma deve essere tenuta segreta in quanto viene utilizzata come chiave di un HMAC o di un meccanismo di cifratura simmetrico applicato al digest della password.

Qualora, quindi, venga utilizzato il pepper, nell’archivio verranno memorizzati gli HMAC o le cifrature dei digest delle password, che andranno confrontati con quelli ottenuti a partire dalle password inserite dagli utenti.

Un’ultima osservazione in merito all’hashing delle password.

Qualora si volesse incrementare il livello di sicurezza del sistema inserendo una funzione di hashing più recente, sarà necessario provvedere all’aggiornamento dei digest delle password salvati nell’archivio.

Gli algoritmi consigliati dalle linee guida ACN

Le linee guida affrontano, poi, il tema degli algoritmi sottolineando come gli stessi siano caratterizzati da diversi parametri, ovvero il costo computazionale, la memoria utilizzata e la possibilità di personalizzazione. In particolare si sottolinea come le singole proprietà degli algoritmi siano personalizzabili e come questa libertà di taratura richieda una responsabilità nella scelta che non deve, in alcun modo, inficiare la sicurezza e l’efficacia dell’algoritmo.

Per i vari algoritmi viene, poi, creata una tabella nella quale vengono indicati i parametri minimi consigliati, tra cui la lunghezza minima del salt, la lunghezza del digest, il numero di iterazioni, l’algoritmo HMAC, i requisiti di memoria e il grado di parallelizzazione.

Conclusioni

Cosa fare quindi per la corretta conservazione delle password? Riassumiamo gli adempimenti indispensabili per garantirne una corretta gestione:

• non salvare in chiaro le password;
• utilizzare procedimenti di hashing password;
• utilizzare algoritmi di password hashing con specifici requisiti, ossia:
• una complessità computazionale tale per cui sia rapido calcolare un singolo digest, ma sia eccessivamente dispendioso calcolarne un numero elevato, così da scoraggiare gli attaccanti a cercare le password degli utenti procedendo per tentativi;
• una capacità di memoria richiesta tale da saturare la RAM quando molti digest vengono calcolati contemporaneamente.
• utilizzare un salt, condizione indicata dalle linee guida come obbligatoria per qualsiasi algoritmo di password hashing, con una lunghezza minima di 128 bit e generato casulamente per ogni password;
• salvare il salt in un archivio differente da quello contenente i digest al fine di innalzare ulteriormente il livello di protezione;
• gli algoritmi scrypt e Argon2id risultano quelli più robusti ed efficienti e dovrebbero, pertanto, essere prioritari rispetto a qualsiasi altra scelta;
• per quanto riguarda i parametri minimi di Argon2id, si sottolinea come aumentare il grado di parallelizzazione p richieda necessariamente l’aumento di almeno uno degli altri due parametri, ovvero il numero di iterazioni c e la memoria richiesta m. Si raccomanda, in ogni caso, di valutare una dimensione adeguata dei parametri di Argon2id in base alla propria capacità computazionale e di memoria, in modo da garantire una rapida esecuzione su una singola password, ma tale da rendere infattibile un numero elevato di esecuzioni;
• qualora venga utilizzato l’algoritmo PBKDF2 lo stesso deve garantire una sicurezza adeguata ed è quindi necessario che si utilizzino le sole funzioni di hash indicate nel documento dedicato, massimizzando il numero c di iterazioni;
• l’algoritmo bcrypt, viene sconsigliato in quanto risulta alquanto datato.

Il rispetto di questi parametri, ovviamente, sarà valutato da parte dell’Autorità garante in un eventuale istruttoria per un data breach, andando ad incidere direttamente sulla quantificazione delle sanzioni che dovessero essere irrogate.