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


148

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 15 * 60 * 60 * 24/1000 ~ = 10 17 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 160 operazioni, il che significa che il nostro attaccante teorico avrebbe bisogno di 10 30 anni per eseguirlo. I limiti di possibilità teoriche sono circa 2 60 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 160 operazioni a 2 157). 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 80 a 2 52 ), 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 106 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?


Ora ha 7 anni e sono successe molte cose dall'ultima modifica. SHA-1 non è più considerato sufficientemente sicuro per l'hash della password
GordonM,

@GordonM cosa è successo? Con la crescita della potenza di calcolo, gli attacchi di collisione SHA-1 stanno diventando sempre più pratici, ma non sono realmente rilevanti qui. SHA-1 non è mai stato veramente sicuro per l'hash della password (generalmente gli hash veloci non lo sono), ma nella misura in cui lo era, è ancora AFAIK.
Tgr

SHA-1 non è mai stato sicuro per l'hash delle password perché non aveva mai avuto intenzione di proteggere le password in primo luogo ...
Azxdreuwa,

Risposte:


209

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 106 secondi nel documento di Kesley e Schneier è un compromesso generico che si applica solo a input molto lunghi (2 60 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 n 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 2 ) 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 ...


5
Risposta eccellente. L'unico elemento con cui non sono d'accordo è "Concettualmente, alzare l'asticella dello stesso fattore per l'utente legittimo e l'attaccante non è in definitiva una buona sicurezza" - l'attaccante deve fare un gran multiplo delle operazioni che un utente deve fare. L'aggiunta di un ciclo di clock per un accesso utente aggiunge milioni per un utente malintenzionato.
Nick Johnson,

1
@Thomas Questo rimane accurato e probabilmente rimarrà accurato per il futuro indefinito prevedibile. Gli hacker possono indovinare le password effettive attraverso qualsiasi tipo di hash a causa della scarsa qualità delle password comuni. Indovina "123456" e otterrai sempre qualche successo. Ciò rimarrà vero indipendentemente dall'archiviazione della password utilizzata.
Tylerl,

1
Solo il mio punto di vista, ma perché dovresti rimanere con SHA1, quando una crittografia della password più potente è già ampiamente disponibile? Un anno fa, MD5 era considerato "sicuro", e ora non lo è - lo stesso potrebbe accadere a SHA1 da un giorno all'altro, per quanto ne sappiamo. Personalmente, scommetto su Blowfish da questo punto in avanti - sembra avere un rappresentante migliore e meno esperti preoccupati nella cripto-comunità, è disponibile quasi ovunque, quindi non c'è motivo di giocare con SHA1.
mindplay.dk,

1
Sono scioccato dal mio cuore di smarrire una risposta di @ThomasPornin dicendo che MD5 è sicuro per l'archiviazione delle password. Se MD5 va bene, perché TUTTO dice di non usarlo, usa bcrypt ?? Sono troppo esagerati? Ho letto e capito tutto ed ero sotto l'impressione che MD5 fosse pessimo perché così vulnerabile alla forza bruta. I commenti recenti di un anno fa non contraddicono la risposta ...
temporaneo

1
@Aerovistae: potresti dare un'occhiata a quella risposta sul sito security.SE; contiene più analisi e dettagli recenti sull'hash delle password.
Thomas Pornin,

30

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:


2
"I moderni algoritmi di hash delle password come bcrypt o PBKDF2 sono progettati specificamente per essere difficili da eseguire su GPU" - intendevi "bcrypt o scrypt"? PBKDF2 è solo hashing iterato, non contiene nulla che possa essere problematico per una GPU.
Tgr

4
Per favore fatemi sapere quale GPU utilizzate, comprerò la stessa. Se è possibile eseguire 2 ^ 160 calcoli SHA-1 in "minuti" (che sarebbe inferiore a "ore", quindi al massimo 59 minuti), è necessario essere in grado di eseguire più di 10 ^ 44 al secondo. Dal momento che PCIe trasferisce il limite a circa 128GT / s, anche la tua GPU deve avere una fantastica memoria integrata. Lo voglio.
Damon,

3
@Damon: sembra che tu abbia assunto password "banali" (<8 bit di entropia) o password "infrangibili" (> 60 bit di entropia). Stai ignorando completamente tutti coloro che hanno una entropia della password compresa tra 10 e 60 bit. Quelli sono gli utenti in cui bcrypt, le tabelle arcobaleno e le GPU, e in genere costituiscono circa l'80% di una base utenti tipica.
Jammycakes,

1
(oops ... avrei dovuto dire, "Quelli sono gli utenti in cui bcrypt, le tabelle arcobaleno e le GPU fanno la differenza più grande")
jammycakes,

3
Per alcune statistiche e analisi, consultare troyhunt.com/2011/06/brief-sony-password-analysis.html - mentre il 36% degli utenti sceglie le password che compaiono nei dizionari delle password, solo il 2-3% sceglie le più comuni.
Jammycakes,

7

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 .


Iterare migliaia di volte non è una buona idea come potresti pensare. Aumenta il rischio di una collisione dell'hash. yorickpeterse.com/articles/use-bcrypt-fool
jammycakes

1
L'articolo sembra completamente confuso. Una funzione di hashing sicura non perde un'entropia apprezzabile attraverso l'hashing iterativo e l'hashing iterativo è una componente fondamentale degli schemi di stiramento dei tasti come PBKDF2 e scrypt. Anche bcrypt, che l'autore raccomanda, usa una costruzione simile. Il suo "attacco" si basa sulla ricerca di un pre-immagine di un hash - nel qual caso, la maggior parte delle costruzioni che usano quell'hash sono comunque completamente distrutte. Infine, non consiglio alle persone di usare direttamente l'hashing iterativo - come ho detto nella mia domanda, dovresti usare una primitiva esistente progettata per lo scopo.
Nick Johnson,

7

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:


4

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.


Può fornire un link? Come ho detto, il miglior attacco preimage che ho trovato rende la ricerca enormemente 8 volte più veloce, e anche per farlo funzionare devi omettere metà dei passaggi di SHA-1. (Inoltre, penso che sia un secondo attacco preimage, che è inutile contro gli hash delle password.)
Tgr

Sono anche scettico su qualcosa che viene dalla NSA, alla luce delle recenti notizie :)
Alex W

4

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.


OK, trovare una collisione SHA-1 ha richiesto circa 6.500 anni CPU e 100 anni GPU , non è un attacco di produzione. Craccare una password non è una forza bruta contro tutti i possibili input ma contro gli elenchi di 10.000.000 di password frequenti. Ecco il documento .
zaph,

1
Il difetto sta usando solo qualsiasi funzione hash per proteggere le password. Il solo utilizzo di una funzione hash non è sufficiente e solo l'aggiunta di un valore sale per migliorare la sicurezza, gli hash crittografici sono molto veloci. Invece, scorrere su un HMAC con un sale casuale per una durata di circa 100 ms e salvare il sale con l'hash. Usare le funzioni come ad esempio PBKDF2(alias Rfc2898DeriveBytes), password_hash/ password_verify, Bcrypte funzioni simili. Il punto è fare in modo che l'attaccante passi molto tempo a trovare le password con la forza bruta. È importante proteggere i tuoi utenti, utilizza metodi di password sicuri.
zaph,

La collisione non è pre-immagine e le password non sono firme. Gli attacchi di collisione non funzionano contro le password perché richiedono la conoscenza del testo in chiaro originale.
Tgr

Tgr: d'accordo, grazie. Zaph: Sì, il sale per salvaguardare dagli attacchi dell'arcobaleno e l'uso di hash cripto lenti sono tra le pratiche raccomandate che non ho affrontato specificamente in questa risposta.
Aaron,

3

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.


Questo è un commento del NIST del 2004. Il loro progetto di raccomandazione del 2010 afferma che SHA-1 è approvato per tutte le applicazioni di generazione di firme non digitali oltre il 2010.
Tgr
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.