Domanda:
L'MD5 è considerato insicuro?
Tawfik Khalifeh
2012-09-08 22:21:57 UTC
view on stackexchange narkive permalink

Dopo che tutti questi articoli sono circolati online sugli exploit md5 , sto valutando la possibilità di passare a un altro algoritmo hash. Per quanto ne so è sempre stato l'algoritmo di scelta tra numerosi DBA. È davvero un vantaggio usare MD5 invece di (SHA1, SHA256, SHA384, SHA512) o è un puro problema di prestazioni?

Quale altro hash consigli (prendendo in considerazione le applicazioni legate ai dati come la piattaforma)? Attualmente sto usando hash salati (hash salati MD5). Considera allo stesso modo sia gli hash dei file md5 che gli hash delle password.

Hai menzionato hash salati, significa che stai parlando di hashing della password? L'hashing della password richiede proprietà diverse dall'hashing normale, il che rende SHA-256 quasi dannoso come MD5 in questo contesto.
Sto usando l'hash md5 per verificare l'integrità dei file critici prima di caricarli e hash md5 salati per le password.
Nessuna delle due è una buona scelta, ma per ragioni completamente diverse.
come quanto male, ho bisogno di comprendere appieno la situazione prima di ricodificare l'intera parte, sono almeno 24 ore sanguinose. la base del codice è come 2K
Probabilmente vorrai leggere [Come eseguire l'hashing sicuro delle password] (http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords). Penso che sia una delle domande più importanti su questo sito.
Sette risposte:
#1
+111
CodesInChaos
2012-09-09 00:10:16 UTC
view on stackexchange narkive permalink

MD5 per le password

Usare md5 salato per le password è una cattiva idea. Non a causa delle debolezze crittografiche di MD5, ma perché è veloce. Ciò significa che un utente malintenzionato può provare miliardi di password candidate al secondo su una singola GPU.

Ciò che dovresti usare sono costruzioni hash deliberatamente lente, come scrypt, bcrypt e PBKDF2. Il semplice SHA-2 salato non è abbastanza buono perché, come la maggior parte degli hash per uso generico, è veloce. Consulta Come eseguire l'hash delle password in modo sicuro? per i dettagli su cosa dovresti usare.

MD5 per l'integrità dei file

L'uso di MD5 per l'integrità dei file può essere un problema pratico, a seconda del tuo esatto scenario di utilizzo.

Gli attacchi contro MD5 sono attacchi di collisione, non attacchi pre-immagine. Ciò significa che un utente malintenzionato può produrre due file con lo stesso hash, se ha il controllo su entrambi. Ma non può abbinare l'hash di un file esistente che non ha influenzato.

Non so se gli attacchi si applichino alla tua applicazione, ma personalmente inizierei la migrazione anche se lo pensi non lo fa. È fin troppo facile trascurare qualcosa. Meglio prevenire che curare.

La soluzione migliore in questo contesto è SHA-2 (SHA-256) per ora. Una volta che SHA-3 sarà standardizzato, sarà anche una buona scelta.

i numeri sono piuttosto spaventosi, [hashcat] (http://hashcat.net/hashcat/) può provare fino a [86,24 M combinazione / i] su 8 thread vincere 7 64 bit (hash md5), è come una nuova era delle password cracking at the loose. bella risposta...
@sarepta hashcat è innocuo rispetto a ocl-hashcat che gira su una GPU. Una singola GPU può raggiungere oltre 6 miliardi di combinazioni al secondo con quello.
Un attacco pre-immagine è teoricamente possibile contro MD5, tuttavia gli attacchi attuali hanno una complessità computazionale di 2 ^ 123,4 per la pre-immagine completa.
Tieni presente che gli attacchi pre-immagine * parziali * sono possibili con MD5. Puoi prendere un file esistente e alterare metadati / aggiungere spazzatura e generare una collisione con un file che generi interamente. Ecco come funziona l'attacco di collisione del certificato SSL MD5.
@ewanm89 - 2 ^ 123.4 non è fattibile (anche con miliardi di GPU che calcolano miliardi di hash MD5 al secondo per miliardi di anni). Sì, è meglio di 2 ^ 128 per un fattore 24, ma la distinzione non ha senso per gli attacchi reali. (Ma d'accordo con altri motivi per evitare MD5).
@Polynomial Non la definirei una pre-immagine parziale. È piuttosto qualcosa come una collisione strutturata.
@CodesInChaos Sì, probabilmente è una descrizione migliore. Erano circa le 7 del mattino quando l'ho scritto!
@drjimbob Non ho ancora detto che fosse fattibile, anche se ci stiamo arrivando, ho solo fatto notare che esiste, e che era un completo attacco pre-immagine. Come altri hanno sottolineato, la pre-immagine parziale è spesso abbastanza buona. Alla nostra velocità attuale con GPU e hardware FPGA che accelerano la forza bruta e continuano a diventare sempre più veloci, probabilmente non passerà molto tempo prima che la pre-immagine completa diventi fattibile.
@sarepta La mia GPU è in grado di gestire ~ 279,5 milioni di combinazioni al secondo per SHA1 e ha un paio di anni ormai. Odio pensare cosa può fare una bella GPU nuova e brillante per il più veloce MD5 ...
Usando le GPU puoi ottenere 33,1 miliardi di hash al secondo per MD5. Le password a 6 caratteri vengono immediatamente tostate.
Gli autori del malware Flame sono riusciti a generare una collisione di prefissi scelti in MD5 che è piuttosto spaventosa, non consiglierei più questo algoritmo per nessuno scopo. SHA-3 è ormai standardizzato AFAIK.
@buherator Non credo che SHA-3 sia ancora standardizzato. Sappiamo che keccak è il vincitore della competizione, ma non sappiamo quali modifiche NIST applicherà prima che diventi SHA-3. Per quanto riguarda l'insicurezza di MD5, non tutte le applicazioni si basano sulla resistenza alle collisioni, quindi non tutte le applicazioni devono migrare urgentemente da MD5. Per i nuovi progetti sicuramente non consiglierei MD5.
Ho visto questo ragionamento (sulla velocità di md5) un certo numero di volte, e mentre sono d'accordo che l'hashing più lento è più sicuro, non capisco il consiglio pratico contro il salting.Quindi, sto salando stringhe con 20 caratteri di sale, la stringa risultante è di almeno 28 caratteri.Ora, un utente malintenzionato può eseguire miliardi di hash al secondo per GPU, diciamo che ha milioni di GPU in esecuzione per un anno.Qual è la possibilità che ottenga la stringa originale?So fare matematica, la probabilità è praticamente 0.
@ivan Un salt viene memorizzato insieme all'hash della password e quindi noto all'aggressore.L'hashing della password è solo l'ultimo livello di difesa quando un utente malintenzionato ha compromesso il server tutti i suoi segreti (comprese le chiavi di crittografia utilizzate per crittografare l'hash della password o pepper).
#2
+36
Thomas Pornin
2013-02-24 09:43:55 UTC
view on stackexchange narkive permalink

Per completare la risposta di @CodesInChaos, MD5 viene spesso utilizzato per la Tradizione , non per le prestazioni. Le persone che si occupano di database non sono le stesse persone che si occupano di sicurezza. Spesso non vedono alcun problema nell'utilizzo di algoritmi deboli (ad esempio, vedere la barzelletta di un algoritmo che MySQL stava usando per l'hashing delle password). Usano MD5 perché usavano MD5 e sono abituati a usare MD5.

Le prestazioni sono molto più spesso discusse che misurate; e tuttavia, logicamente, non può esserci un problema di prestazioni se non c'è nulla da misurare. Utilizzando un core di una CPU di base, è possibile eseguire l'hashing di più di 400 MByte al secondo con MD5, più vicino a 300 MB / s con SHA-1 e 150 MB / s con SHA-256. D'altra parte, un disco rigido decente produrrà dati a una velocità ancora inferiore (da 100 a 120 MB / s sarebbe tipico), quindi la funzione hash non è quasi mai il collo di bottiglia. Di conseguenza, non ci sono problemi di prestazioni relativamente all'hashing nei database.

Le solite raccomandazioni, per le funzioni hash, sono:

  1. Non farlo. Non dovresti usare algoritmi crittografici elementari, ma protocolli che assemblano diversi algoritmi in modo da fornire collettivamente alcune caratteristiche di sicurezza (ad esempio trasferimento di dati con riservatezza e integrità).

  2. Davvero, non farlo. Per memorizzare le password (più precisamente, i token di verifica della password), non creare un mix personalizzato di una funzione hash e sali; utilizzare una costruzione studiata appositamente per tale uso. Questo normalmente significa bcrypt o PBKDF2.

  3. Se una funzione hash è effettivamente ciò che fa il lavoro, allora usa SHA-256. Prendi in considerazione l'utilizzo di qualsiasi altra funzione solo se qualche problema serio con SHA-256 (molto probabilmente le sue prestazioni ) è stato debitamente rilevato e misurato.

Vedo la tua risposta come: "Non utilizzare direttamente le funzioni hash: utilizza un sistema più grande come TLS per il trasferimento dei dati, certificati per l'autenticazione e / o bcrypt o PBKDF2 per l'archiviazione delle password".
#3
+6
Bradley Kreider
2012-09-10 07:11:10 UTC
view on stackexchange narkive permalink

Attualmente sto usando hash salati (hash salati MD5).

Se stai salando hash MD5, sicuramente non vorrai usare MD5. Sembra che tu debba usare PBKDF2 o bcrypt.

Per quanto ne so è sempre stato l'algoritmo di scelta tra numerosi DBA.

Non è così un motivo convincente.

Ho lavorato con molti amministratori di database che sono indietro di almeno 5 anni nella tecnologia generale (non usano il controllo della versione, script Perl non formattati per tutto, ecc.). Potrebbero essere stati amministratori di database particolarmente pessimi, ma penso che venga fornito con la mentalità estremamente conservatrice di non cambiare le cose.

#4
+4
Machavity
2015-10-28 19:28:09 UTC
view on stackexchange narkive permalink

Solo per completare le risposte già fornite (la maggior parte delle quali sono eccellenti) ora abbiamo un esempio del mondo reale in cui una violazione dei dati (Ashley Madison) ha portato alla fuga dell'intera tabella delle password. Hanno usato bcrypt con un salt casuale per hash le password. Un ricercatore di sicurezza ha deciso di prendere quegli hash e di forzarli. Questo è stato il risultato

Come risultato di tutto ciò, bcrypt sta ponendo richieste erculee a chiunque cerchi di rompere la discarica di Ashley Madison per almeno due motivi. Innanzitutto, 4.096 iterazioni di hashing richiedono enormi quantità di potenza di calcolo. Nel caso di Pierce, bcrypt ha limitato la velocità del suo impianto di cracking a quattro GPU a un misero 156 tentativi al secondo. Secondo, poiché gli hash bcrypt sono salati, il suo rig deve indovinare il testo in chiaro di ogni hash uno alla volta, piuttosto che tutti all'unisono.

"Sì, è vero, 156 hash al secondo", ha scritto Pierce. "Per qualcuno che è abituato a decifrare le password MD5, questo sembra piuttosto deludente, ma è bcrypt, quindi prenderò quello che posso ottenere."

Pierce ha rinunciato una volta superato il punteggio di 4.000. Per eseguire tutti i sei milioni di hash nel pool limitato di Pierce contro le password di RockYou avrebbe richiesto ben 19.493 anni, ha stimato. Con un totale di 36 milioni di password con hash nella discarica di Ashley Madison, ci sarebbero voluti 116.958 anni per completare il lavoro.

Alla fine della giornata, le uniche che è riuscito a decifrare erano password ridicolmente semplici o comuni (come "123456").

In realtà, alcuni di loro erano disponibili come hash MD5 (o da un vecchio sistema o qualcos'altro, non ne sono sicuro).Quelli erano crackati nessun problema.
#5
  0
Matrix
2012-09-08 22:37:08 UTC
view on stackexchange narkive permalink

Sì, MD5 non è sicuro, così come SHA-1, consiglio di utilizzare SHA-256 se la dimensione del digest è un problema. Ricorda, se lo archivi in ​​una colonna BINARIA, ci vorrà meno spazio che se memorizzato in CHAR. Assicurati solo che sia fatto correttamente. MD5 è circa 2,3 volte più veloce di SHA-256. Altri benchmark sono disponibili su http://www.cryptopp.com/benchmarks.html

Non utilizzare hash standard per l'archiviazione delle password. Sono troppo veloci. PBKDF2 / bcrypt sono la strada da percorrere.
#6
  0
Shane
2013-06-20 13:50:08 UTC
view on stackexchange narkive permalink

Per farla breve, ora è piuttosto insicuro a causa delle tabelle arcobaleno, la tabella Arcobaleno è un elenco di hash MD5 e le loro stringhe corrispondenti. Quindi fondamentalmente prenderei in considerazione altre alternative come SHA1

Le tabelle arcobaleno si applicano quasi allo stesso modo a tutti gli hash non salati. La migrazione a SHA1 o SHA2 non farebbe quasi nulla. L'approccio corretto per l'hashing della password consiste nell'usare un salt insieme a una funzione di hashing della password deliberatamente lenta come PBKDF2, bcrypt o scrypt. Anche con hash veloci non salati è spesso più economico eseguire una nuova ricerca GPU rispetto all'utilizzo di una tabella arcobaleno.
#7
-1
Dom
2013-06-20 12:57:21 UTC
view on stackexchange narkive permalink


Parlate tutti di insicurezza, ma nessuno di voi ha risposto direttamente alla domanda.

Ho lavorato con MD5 e Sha512, entrambi facili da risolvere una volta che ho aveva messo il mio piccolo esperto di hacker su di esso, fino a quando non ci ha colpito entrambi come un tuono! Il modo più semplice ed efficace per fermare "attacchi di massa" come quelli descritti sopra, è impostare un limitatore di tentativi di accesso, ovvero:

  function checkbrute ($ user_id, $ mysqli) {// Ottieni il timestamp dell'ora corrente $ now = time (); // Tutti i tentativi di accesso vengono conteggiati dalle ultime 2 ore. $ tentativi_validi = $ ora - (2 * 60 * 60); if ($ stmt = $ mysqli->prepare ("SELECT time FROM login_attempts WHERE user_id =? AND time > '$ valid_attempts'")) {$ stmt->bind_param ('i', $ user_id); // Esegue la query preparata. $ stmt->execute (); $ stmt->store_result (); // Se ci sono stati più di 5 accessi falliti if ($ stmt->num_rows > 5) {return true; } else {return false; }}}  


Hai capito?
Il numero massimo di combinazioni che l'hacker vuole provare, è limitato a 5 fallimenti ogni 2 ore. Puoi persino bloccare l'utente dopo X tentativi.

Non stai tenendo conto dei backup rubati / scartati in modo improprio dei database degli utenti o dei record degli utenti recuperati in massa tramite qualche exploit (ad esempio un SQLi). La tua risposta riguarda l'hacking dei database live attraverso e tramite l'applicazione server che dovrebbe essere l'unica ad accedere a tali dati, un account utente alla volta, che - se questo fosse l'unico rischio - potrebbe essere risolto in modo molto più elegante e password gli hash non sarebbero necessari in primo luogo. Non mi credi? Chiedi a [LinkedIn] (http://www.zdnet.com/blog/btl/6-46-million-linkedin-passwords-leaked-online/79290) (tra molti altri);)
1) Ho scritto esplicitamente che MD5 e SHA-2 non sono sicuri come hash delle password. 2) Non sono noti attacchi a SHA-512 se usati correttamente. È un hash crittografico, non un hash della password. 3) Ti manca il punto degli hash delle password. Lo scopo di un hash della password è proteggere le password quando il database è trapelato. In questo scenario un limitatore di velocità non aiuta affatto.
FWIW che limita i tentativi di accesso in questo modo rende molto semplice eseguire la negazione del servizio
@EricGrange: Ovviamente li limiti per ogni IP o qualsiasi altra cosa, non in totale.
@Evi1M4chine nell'era di IPv6, un utente malintenzionato può facilmente (ed a buon mercato) avere milioni di indirizzi IPv6 diversi


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...