Gli attacchi di collisione non hanno alcun impatto sulla password hashing , anche se possono esserci alcuni dettagli a seconda di cosa si ha per hash. In parole povere, quando abbiamo cancellato le password, potremmo voler fare due cose:
-
Verifica che l'hash della password abbia un determinato valore memorizzato: questa è verifica della password (ad esempio per sapere se concedere l'accesso di accesso a un server).
-
Calcola una chiave simmetrica grande deterministicamente dalla password: questa è la derivazione della chiave (ad esempio per crittografare un file).
La verifica della password funziona solo sulla resistenza alle pre-immagini (la difficoltà nel trovare un valore m tale che h (m) corrisponda a un dato risultato). Tuttavia, la derivazione delle chiavi richiede un po 'di più. Idealmente, per la derivazione della chiave, la funzione di hash dovrebbe comportarsi il più vicino possibile al mitico oracolo casuale . Sappiamo già che le funzioni hash si basano sulla costruzione Merkle-Damgård , come MD5 o SHA-256, sono non oracoli casuali (a causa dell '"attacco di estensione della lunghezza"); tuttavia, possiamo utilizzare tali funzioni in HMAC , che usa due invocazioni di funzioni hash annidate precisamente per evitare problemi con la costruzione di MD. Ma HMAC è "provato" sicuro solo relativamente a una proprietà interna della funzione hash (vale a dire, la "funzione di compressione" interna dovrebbe essere indistinguibile da un PRF) e sappiamo che questa proprietà non è soddisfatta in il caso di MD5, perché altrimenti gli attacchi di collisione non sarebbero fattibili ...
Per riassumere, quando si utilizza MD5 per la derivazione delle chiavi, è necessario applicare schemi come HMAC-DRBG (un PRNG basato su ripetute invocazioni HMAC), che utilizzano internamente MD5. Tali schemi sono noti per essere forti fino a quando la funzione di hash è strong, e mentre gli attacchi di collisione non si applicano direttamente, mostrano che questa "forza" non è raggiunta. Quindi, la garanzia è nulla. Nessuno sa, al momento, come indebolire HMAC / MD5, ma abbiamo l'esempio di MD4: MD4 è completamente rotto per le collisioni (le collisioni possono essere prodotte "istantaneamente"), e c'è un attacco noto su HMAC / MD4 che è abbastanza costoso ma nondimeno molto più veloce del teorico 2 128 . Gli attacchi su HMAC / MD4 non sfruttano le collisioni, ma si basano su percorsi differenziali che sono la stessa fonte da cui sono stati progettati gli attacchi di collisione. Pertanto, altamente sospetto che HMAC / MD5 non è strong come, per esempio, HMAC / SHA-256 (anche se troncato a 128 bit).
Corrispondentemente, per la derivazione della chiave, non usare MD5. Non sarebbe rotto subito , ma sta ancora cercando problemi. Non è necessario eseguire immediatamente la migrazione dei sistemi esistenti che utilizzano MD5 per l'hashing delle password, ma per i nuovi progetti, è necessario evitarlo.
Promemoria obbligatorio:
Ovviamente, quando si utilizzano password di hashing, indipendentemente dall'utilizzo previsto (verifica della password o derivazione della chiave), si applicano i sali e la lentezza configurabile . Una password è di per sé una debolezza a causa delle limitazioni biologiche del cervello umano che la gestisce. I sali e la lentezza configurabile sono i modi per affrontarlo: i sali ostacolano il parallelismo (l'attaccante non può condividere i costi di attacco tra diverse istanze di password, ad esempio attraverso tabelle precalcolate come tavole arcobaleno ) e sconfitte di lentezza legge di Moore (i computer diventano più veloci nel tempo, ma umani il cervello non lo fa). Quindi non vorrai digitare una password con "solo MD5", ma piuttosto usare una funzione di hashing della password dedicata come PBKDF2 o bcrypt . PBKDF2 utilizza internamente una funzione di hash, ad es. MD5. Accade così che MD5 (come SHA-256) si adatti molto bene alle capacità di calcolo di GPU , il che rende discutibile scelta per questo lavoro, e bcrypt è indubbiamente migliore (si veda questa risposta per i dettagli ).