Va bene racchiudere un hash crittografico con MD5 per l'archiviazione?

Non perdi nulla applicando MD5.

Poiché utilizzi md5(hash()) come schema di hashing combinato, presumibilmente l'autore dell'attacco non ha la possibilità di inviare un input che viene valutato solo da md5() ; è valutato dall'intero schema o niente del tutto. Quindi, dato un hash h nel tuo database, l'obiettivo dell'attaccante è di trovare m tale che md5(hash(m)) = h . ( m può o non può essere la password originale, poiché una password di collisione è sufficiente per consentire l'accesso fraudolento.)

Supponendo che l'attacker abbia ottenuto h e sono stati in grado di sfruttare una debolezza in MD5 e trovare una pre-immagine h' tale che MD5(h') = h , che non li aiuta dal momento che devono ancora trovare la pre-immagine di h' in hash . Se hash è sufficientemente strong a sé stante, non è più debole dell'utilizzo di hash di per sé.

L'essenza dell'idea qui è che MD5 si comporta come una mappa casuale di ingressi e uscite. La mappatura di MD5 è ben distribuita e le stringhe casuali non generano collisioni. Per quanto riguarda la sicurezza, MD5 rende troppo facile creare collisioni in modo intelligente, ma non ci interessa che l'autore dell'attacco crea in modo intelligente l'input per MD5 in questo caso, ci interessa solo aggiungendo una mappatura all'output di hash non creare più collisioni con MD5(hash()) del previsto di hash di per sé. In altre parole, non state facendo affidamento sulle proprietà resistive alle collisioni crittografiche di MD5. È possibile aggiungere qualsiasi tipo di mappatura casuale all'output di una buona funzione di hash e, finché tale mappatura non è soggetta a collisioni accidentali, non si dovrebbe perdere nulla.

Indirizzamento alla parte aggiornata dell'OP: è possibile utilizzare SHA-512 e troncare l'output. Il standard FIPS-140-4 recente specifica di troncare SHA-512 a una manciata di lunghezze. Questo è un metodo completamente approvato.

È meglio troncare l'output dell'hash originale.

Per prima cosa, fai attenzione all'archiviazione di sale: per verificare una password, dovrai ricalcolare l'hash della password, usando lo stesso conteggio di sale e iterazione. Alcune funzioni di hash (vale a dire bcrypt ) codificano tradizionalmente il conteggio di sale e iterazione nell'output. Se si mantiene solo un hash dell'output di bcrypt ma non il sale stesso da qualche parte, non sarà possibile ricalcolare l'hash da una determinata password, interrompendo la funzionalità.

Quindi, l'hashing della password funziona con la resistenza all'immagine preliminare . Se la funzione di hash che usi è buona, la sua resistenza alle preimmagini sarà nell'ordine di 2 ⁿ con un output di bit n . Pertanto, è possibile troncare l'output (l'output effettivo bit , senza contare la codifica di sale e il numero di iterazioni e ignorando qualsiasi trasformazione dei bit in caratteri con esadecimale o Base64 ) fino a, diciamo, 80 bit. Se la funzione di hash è buona, sarà abbastanza robusta. Non c'è bisogno di rifare con MD5 o qualsiasi altra funzione; un semplice truncate farà il trucco. E se la funzione di hash è non buona e introduce punti deboli quando viene così troncata, allora ... perché la useresti in primo luogo?

(Le collisioni non hanno nulla a che fare con il problema. Le collisioni sono irrilevanti per l'hashing delle password. L'applicazione di MD5 sull'output non indurrebbe alcuna debolezza significativa, nonostante la non-resistenza di MD5 alle collisioni, poiché l'hashing delle password riguarda le pre-immagini. il troncamento è più semplice e "più semplice" significa "buono" in sicurezza, ma è anche più flessibile poiché puoi scegliere la lunghezza come meglio credi.)

L'uso di MD5 in questo caso va bene, ma non è necessario utilizzare MD5 per ridurre la lunghezza della stringa hash. Basta eseguire una semplice operazione sulla stringa hash per ridurne la lunghezza. Ad esempio, se la stringa hash a lunghezza intera è:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Puoi ridimensionarlo in base alla lunghezza accettabile per l'archiviazione, ad esempio:

e3b0c44298fc1c149afbf4c8996fb9242

Penso che MD5 (hash (password)) non abbia alcuna debolezza pratica nota, se hai bisogno di troncare l'hash a 16 byte. Leggi la risposta di B-Con per la spiegazione. Nota che ciò si basa su alcune proprietà della funzione MD5, non solo sulle proprietà della funzione di hash. Ad esempio, supponiamo che si sia scoperto che MD5 non è effettivamente suriettivo (per quanto ne so, questo non è noto) e ci sono solo N diversi valori digest MD5. Quindi trovare un altro hash con lo stesso MD5 sarebbe una questione di calcolo dell'hash di N password diverse, che potrebbe essere praticabile se N non è troppo grande.

Tuttavia, se lo fai, sarai colpevole di rotolare la tua cripto. Non rollare la tua crittografia .

Fortunatamente, c'è un modo migliore per ottenere un valore di 16 byte da una funzione di hash che è ancora una funzione di hash. Con una buona funzione di hash, ogni bit è il più indipendente possibile dagli altri bit e non rivela alcuna informazione sull'hash. Pertanto, se si prendono 128 bit da un hash, si ottiene un hash a 128 bit. Per la famiglia SHA, questo è ufficialmente accettato (FIPS 180-4 §7): se vuoi un hash N-bit, puoi utilizzare una funzione hash approvata che produce più di N bit e tronca ai primi N bit . I consigli NIST per l'utilizzo degli hash (§5.1) discutono forza che puoi aspettarti da un troncamento a N bit.

Se stai facendo questo perché hai un campo di database a dimensione fissa che era destinato ai digest MD5, tieni presente che mentre è accettabile troncare il digest, il sale non è negoziabile. È necessario disporre di un sale unico e in qualche modo deve essere memorizzato nel database. Il sale di ogni utente deve essere distinto sia da quello di qualsiasi altro utente sia da un sale utilizzato in qualsiasi altro database. (Le collisioni saline possono essere tollerate se sono abbastanza rari, ma se due utenti hanno la stessa password e lo stesso sale, ciò sarà ovviamente visibile.) Il sale può essere generato da altri campi, ma non è un buona idea, perché è difficile raggiungere l'unicità; vedi Chiave primaria come sale? . Altro sfondo sul sale: Cosa dovrebbe essere usato come sale? Come conservare il sale? Perché usare il sale è più sicuro?

Sebbene non ci siano attacchi espliciti di cui sono a conoscenza, non lo consiglio. MD5 è rotto e ha molte collisioni note. In quanto tale, un utente malintenzionato potrebbe essere in grado di generare input in modo tale che l'output di KDF sia una collisione con un'altra password.

Invece, perché non utilizzare un KDF come PBKDF2 con una dimensione di output modificabile?

Sì, c'è un problema.

L'hash MD5 risultante è proprio questo. Un hash MD5. Sarebbe soggetto a attacchi di collisione contro di esso.

MD5 è una funzione hash con vulnerabilità di collisione note. Evita di usarlo se possibile.