SHA-1 è sicuro per l'archiviazione della password?

Conclusione: SHA-1 è sicuro come qualsiasi altro contro gli attacchi preimage, tuttavia è facile da calcolare, il che significa che è più facile montare un attacco bruteforce o un dizionario. (Lo stesso vale per i successori come SHA-256.) A seconda delle circostanze, una funzione hash progettata per essere computazionalmente costosa (come bcrypt) potrebbe essere una scelta migliore.

Alcune persone lanciano spesso commenti come "SHA-1 è rotto", quindi sto cercando di capire cosa significhi esattamente. Supponiamo che io abbia un database di hash di password SHA-1 e un attaccante con un algoritmo di rottura SHA-1 all'avanguardia e una botnet con 100.000 macchine vi acceda. (Avere il controllo di oltre 100.000 computer domestici significherebbe che possono fare circa 10 ^ 15 operazioni al secondo.) Quanto tempo dovrebbero

1. scoprire la password di un singolo utente?
2. scoprire la password di un determinato utente?
3. scopri la password di tutti gli utenti?
4. trovare un modo per accedere come uno degli utenti?
5. trovare un modo per accedere come utente specifico?

Come cambia se le password sono salate? È importante il metodo di salatura (prefisso, postfisso, entrambi o qualcosa di più complicato come lo xoring)?

Ecco la mia attuale comprensione, dopo aver cercato su Google. Per favore, correggi nelle risposte se ho frainteso qualcosa.

• Se non c'è sale, un attacco arcobaleno troverà immediatamente tutte le password (tranne quelle estremamente lunghe).
• Se esiste un sale casuale sufficientemente lungo, il modo più efficace per scoprire le password è una forza bruta o un attacco da dizionario. Né gli attacchi di collisione né pre-immagine sono di alcun aiuto nel trovare la password effettiva, quindi gli attacchi crittografici contro SHA-1 non sono di aiuto qui. Non importa nemmeno quale algoritmo venga utilizzato: si potrebbe persino usare MD5 o MD4 e le password sarebbero altrettanto sicure (c'è una leggera differenza perché il calcolo di un hash SHA-1 è più lento).
• Per valutare quanto sia sicuro "altrettanto sicuro", supponiamo che una singola esecuzione sha1 richieda 1000 operazioni e che le password contengano lettere maiuscole, minuscole e cifre (ovvero 60 caratteri). Ciò significa che l'attaccante può testare 10 ¹⁵ * 60 * 60 * 24/1000 ~ = 10 ¹⁷ potenziali password al giorno. Per un attacco di forza bruta, ciò significherebbe testare tutte le password fino a 9 caratteri in 3 ore, fino a 10 caratteri in una settimana, fino a 11 caratteri in un anno. (Ci vuole 60 volte di più per ogni personaggio aggiuntivo.) Un attacco con dizionario è molto, molto più veloce (anche un utente malintenzionato con un singolo computer potrebbe farlo in poche ore), ma trova solo password deboli.
• Per accedere come utente, l'utente malintenzionato non deve trovare la password esatta; è sufficiente trovare una stringa che dia lo stesso hash. Questo è chiamato un primo attacco preimage. Per quanto ho potuto trovare, non ci sono attacchi preimage contro SHA-1. (Un attacco bruteforce richiederebbe 2 ¹⁶⁰ operazioni, il che significa che il nostro attaccante teorico avrebbe bisogno di 10 ³⁰ anni per eseguirlo. I limiti di possibilità teoriche sono circa 2 ⁶⁰ operazioni, a cui l'attacco richiederebbe alcuni anni.) Ci sono attacchi preimage contro versioni ridotte di SHA-1 con effetto trascurabile (per SHA-1 ridotto che utilizza 44 passi invece di 80, il tempo di attacco è passato da 2 ¹⁶⁰ operazioni a 2 ¹⁵⁷). Ci sono attacchi di collisione contro SHA-1 che sono ben all'interno delle possibilità teoriche ( il migliore che ho trovato riduce il tempo da 2 ⁸⁰ a 2 ⁵² ), ma quelli sono inutili contro gli hash delle password, anche senza salare.

In breve, la memorizzazione delle password con SHA-1 sembra perfettamente sicura. Ho dimenticato qualcosa?

Aggiornamento: Marcelo ha sottolineato un articolo che menziona un secondo attacco preimage in 2 ¹⁰⁶ operazioni . ( Modifica: Come spiega Thomas , questo attacco è un costrutto ipotetico che non si applica agli scenari della vita reale.) Tuttavia non vedo ancora come ciò comporti un pericolo per l'uso di SHA-1 come funzione di derivazione chiave. Ci sono generalmente buone ragioni per pensare che un attacco di collisione o un secondo attacco di preimage possano alla fine trasformarsi in un primo attacco di preimage?

La risposta breve alla tua domanda è: SHA-1 è il più sicuro possibile. Anche MD5 andrebbe bene, anche MD4; ma potrebbe innervosire alcuni investitori. Per le pubbliche relazioni , è preferibile utilizzare una funzione hash "migliore", ad esempio SHA-256, anche se si tronca l'output a 160 o 128 bit (per risparmiare sui costi di archiviazione). Alcuni dei candidati SHA-3 round-2 sembrano essere più veloci di SHA-1 pur essendo probabilmente "più sicuri"; eppure sono ancora un po 'nuovi, quindi attenersi a SHA-256 o SHA-512 sarebbe un percorso più sicuro in questo momento. Ti farebbe apparire professionale e cauto, il che è positivo.

Si noti che "il più sicuro possibile" non è lo stesso di "perfettamente sicuro". Vedi sotto per spiegazioni piuttosto lunghe.

Informazioni sugli attacchi noti:

Gli attacchi noti su MD4, MD5 e SHA-1 riguardano collisioni, che non influiscono sulla resistenza preimmaginata. È stato dimostrato che MD4 presenta alcuni punti deboli che possono essere (solo teoricamente) sfruttati quando si tenta di interrompere HMAC / MD4, ma ciò non si applica al problema. L' attacco preimage di 2 ¹⁰⁶ secondi nel documento di Kesley e Schneier è un compromesso generico che si applica solo a input molto lunghi (2 ⁶⁰ byte; questo è un milione di terabyte - nota come 106 + 60 supera 160; è lì che vedi che il compromesso non ha nulla di magico in esso).

Il resto di questo messaggio presuppone che la funzione hash utilizzata (ad esempio SHA-1) sia una "scatola nera" senza proprietà speciali che l'utente malintenzionato può utilizzare. Questo è quello che hai adesso anche con le funzioni hash "rotte" MD5 e SHA-1.

Informazioni sui tavoli arcobaleno:

L '"attacco arcobaleno" è in realtà la condivisione dei costi di un dizionario o un attacco di forza bruta. È un derivato del trade-off di memoria del tempo descritto per la prima volta da Hellman nel 1980. Supponendo che tu abbia N possibili password (che sono le dimensioni del tuo dizionario, o 2 ⁿ se consideri la forzatura bruta di una funzione hash con un output di n bit), c'è un attacco di condivisione del tempo in cui precomponi le password con hash N e le memorizzi in un grande tavolo. Se si ordinano gli output hash, è possibile ottenere la password in una singola ricerca. Un tavolo arcobaleno è un modo intelligente per conservare quel tavolo con uno spazio molto ridotto. Memorizzi solo le password con hash N / t e le password con O (t ² ) ricerche. Le tabelle Rainbow consentono di gestire virtualmente tabelle precompilate molto più grandi di quelle che è possibile archiviare realisticamente.

Tuttavia, arcobaleno o no, l'attaccante deve ancora eseguire l'intero attacco almeno una volta. Questo può essere visto come diversi livelli di ottimizzazione successivi:

1. L'attacco a forza bruta / dizionario ha un costo N per decifrare ogni password.
2. Con una tabella pre-calcolata, l'attaccante paga una volta N che costa e può in seguito attaccare molte password con un costo aggiuntivo molto ridotto per password.
3. Se la tabella pre-calcolata è una tabella arcobaleno, allora N può essere leggermente più grande, poiché i costi di archiviazione sono ridotti. Il collo di bottiglia su N diventa la potenza della CPU che può attaccare l'attaccante, non le dimensioni dei suoi hard disk.

Se N è abbastanza grande da rendere ridicolo il costo della CPU dell'hashing di N password, allora un tale attacco non è fattibile, indipendentemente dal fatto che vengano utilizzate o meno tabelle arcobaleno. Ciò significa che una funzione hash (preimage resistente) con un'uscita di 80 bit o più è sufficiente per rendere impossibile l'attacco a forza bruta.

A proposito di sali:

I sali sono un modo per sconfiggere i pre-calcoli. Nella descrizione sopra, il salt riporta l'aggressore al passaggio 1: il salting impedisce all'attaccante di condividere il costo O ( N ) tra diverse password attaccate. Le tabelle pre-calcolate, a fortiori arcobaleno, non sono più possibili.

Vuoi salare perché quando i dati con hash sono costituiti da password , cioè qualcosa che si adatta al cervello di un essere umano casuale, allora N può essere piuttosto basso: gli umani sono davvero cattivi nel scegliere e ricordare le password. Questi sono gli "attacchi ai dizionari": utilizzare uno spazio ridotto di potenziali password (il "dizionario") presupponendo che molte password utente si trovino in quello spazio appositamente selezionato.

Quindi la salatura impedirà almeno all'attaccante di usare tabelle pre-calcolate, in particolare tabelle arcobaleno pre-calcolate. Ciò presuppone che l'attaccante sarà in grado di violare una o due password; non vogliamo che rompa altre 1000 password con un piccolo sovraccarico aggiuntivo.

Inoltre, la salatura fa bene alle pubbliche relazioni.

Informazioni sul costo SHA-1:

Il costo elementare di SHA-1 riguarda l'hashing di un blocco a 64 byte. Ecco come funziona SHA-1: i dati vengono riempiti, quindi divisi in blocchi da 64 byte. Il costo dell'elaborazione di un singolo blocco è di circa 500 cicli di clock su un sistema Intel Core2, e questo è per un singolo core. MD5 e MD4 sono più veloci, contano rispettivamente circa 400 e 250 cicli. Non dimenticare che la maggior parte delle CPU moderne ha diversi core, quindi moltiplica di conseguenza.

Alcuni schemi di salatura prescrivono enormi sali; ad esempio, ciò che entra nella funzione hash sono in realtà 40000 copie successive di un singolo salt a 128 bit, seguito dalla password stessa. Questo rende l'hashing delle password più costoso (di un fattore 10000 con il mio esempio), sia per l'utente legittimo che per l'attaccante. Se questa è una buona idea dipende dalla configurazione. Per il login su un sistema desktop, questo è buono: l'utente non noterà nemmeno che ci sono voluti 10ms per eseguire l'hashing della sua password, anziché 1µs; ma il costo per l'attaccante è aumentato di un fattore molto evidente di 10000. Sui server condivisi con migliaia di client al secondo, il costo aggregato può diventare proibitivo. Concettualmente, alzare il tiro dello stesso fattore per l'utente legittimo e l'attaccante non è in definitiva una buona sicurezza; ma può essere un'idea utile in alcune situazioni specifiche.

Informazioni sugli attacchi online:

Tutto quanto sopra riguarda la sconfitta degli attacchi offline . Un attacco offline è un attacco in cui l'attaccante ha tutti i dati di cui ha bisogno per "testare" le password; ad es. l'attaccante potrebbe ottenere una copia del database contenente le password con hash. In un attacco offline, l'attaccante è limitato solo dalle sue risorse computazionali. Al contrario, un attacco online è un attacco in cui ogni ipotesi dell'attaccante deve passare attraverso un verificatore onesto (ad es. L'attaccante tenta semplicemente di accedere al sistema attaccato). Gli attacchi online vengono contrastati applicando limiti al numero di password che possono essere provate al secondo. Esempi estremi sono le smart card che si chiudono dopo tre PIN errati.

Di solito, per la sicurezza della password, è molto più utile organizzare il sistema in modo da non consentire a un utente malintenzionato di creare un attacco offline. Questo è ciò che fanno i sistemi Unix: le password con hash, che prima erano nel /etc/passwordfile leggibile dal mondo , sono ora nel /etc/shadowfile che è protetto dall'accesso in lettura, tranne che da alcune applicazioni privilegiate. Il presupposto qui è che se l'aggressore può leggere /etc/shadow, allora probabilmente ha abbastanza controllo sul sistema da non avere più bisogno delle password ...

Le risposte precedenti non fanno alcun riferimento alle GPU, che possono parallelizzare l'hash SHA-1 nella misura in cui un intero database può ora essere forzato brutalmente in minuti o ore anziché giorni o settimane, anche se le password sono state salate.

I moderni algoritmi di hash delle password come bcrypt o scrypt sono progettati specificamente per essere difficili da eseguire su GPU a causa del fatto che sono blocchi di codice con requisiti di memoria molto più elevati (e l'accesso alla memoria in una GPU non può essere parallelizzato nella stessa misura). Hanno anche una "funzione di lavoro" che consente loro di essere rallentati al volo man mano che la tecnologia migliora.

In breve, dovresti usare solo gli strumenti migliori per il lavoro. E SHA-1 è molto al di sotto dello stato dell'arte.

Per ulteriori letture:

• /crypto/400/why-cant-one-implement-bcrypt-in-cuda
• http://codahale.com/how-to-safely-store-a-password/
• http://www.codinghorror.com/blog/2012/04/speed-hashing.html
• /security/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

La tua descrizione sembra accurata per lo stato dell'arte attuale.

Non dovresti usare una singola iterazione di nessuna funzione hash, comunque: Almeno, dovresti iterare molte volte (1000 iterazioni dell'hash aumentano il lavoro dell'attaccante di 1000 volte. Aumenta il tuo lavoro della stessa quantità, ma stai eseguendo molto meno hashing delle password rispetto a loro).

Idealmente, tuttavia, è necessario utilizzare una primitiva di archiviazione password esistente, come quelle descritte qui .

SHA1 è un digest di messaggi , non è mai stato pensato per essere una funzione di hashing della password (o derivazione della chiave). (Anche se potrebbe essere utilizzato un blocco predefinito per un KDF, come in PBKDF2 con HMAC-SHA1.)

Una funzione di hashing della password dovrebbe difendersi dagli attacchi del dizionario e dalle tabelle arcobaleno. Diversi algoritmi sono stati progettati per raggiungere questo obiettivo.

Attualmente, la scelta migliore è probabilmente Argon2 . Questa famiglia di funzioni di hashing delle password ha vinto la competizione di hashing delle password nel 2015.

Se Argon2 non è disponibile, l'unica altra funzione standardizzata di hashing o derivazione delle chiavi è PBKDF2 , che è un vecchio standard NIST. Altre opzioni, se non è richiesto l'uso di uno standard, includono bcrypt e scrypt .

Wikipedia ha pagine per queste funzioni:

• https://en.wikipedia.org/wiki/Argon2
• https://en.wikipedia.org/wiki/Bcrypt
• https://en.wikipedia.org/wiki/Scrypt
• https://en.wikipedia.org/wiki/PBKDF2

Sono state scoperte serie vulnerabilità in SHA-1 che rendono la ricerca molto più veloce della forza bruta. È ancora in gran parte intrattabile, ma non è previsto che sia il caso per troppo tempo; i programmatori paranoici preferiscono qualcosa della famiglia SHA-2.

Da questo articolo relativo al risultato originale del 2005:

"È ora di camminare, ma non di correre, verso le uscite antincendio. Non vedi fumo, ma gli allarmi antincendio sono stati disattivati."

Non è che l'attuale crittoanalisi rende SHA-1 insicuro, ma piuttosto che la comunità crittografica è preoccupata che notizie peggiori potrebbero essere proprio dietro l'angolo. Questa paura si applica anche a SHA-2, che presenta gli stessi difetti di SHA-1, anche se su uno spazio di ricerca molto più ampio, da cui la continua ricerca di SHA-3 .

In breve, SHA-1 è sicuro in questo momento, e probabilmente lo sarà per qualche tempo, ma la comunità crittografica è a disagio con la prognosi.

A partire da febbraio 2017, SHA-1 non dovrebbe più essere considerato sicuro. Google ha segnalato il successo con attacchi di collisione contro l'intero SHA-1 non ridotto ( link per segnalare ). Per l'annuncio di Google, fai clic qui .

Modifica: come sottolineato da altri, le password non sono vulnerabili agli attacchi di collisione dell'hash. Tuttavia, come linea guida generale, non sceglierei SHA-1 per le applicazioni relative alla sicurezza. Ci sono alternative migliori là fuori.

Se si memorizza la password salata, SHA-1 va bene per scopi pratici. SHA-2 è considerato più sicuro, ma SHA-1 non è un problema a meno che tu non abbia un motivo per essere veramente paranoico.

Ecco cosa dice NIST :

I risultati presentati finora su SHA-1 non mettono in discussione la sua sicurezza. Tuttavia, a causa dei progressi tecnologici, il NIST prevede di eliminare gradualmente SHA-1 a favore delle funzioni di hash più grandi e più potenti (SHA-224, SHA-256, SHA-384 e SHA-512) entro il 2010.