Memoria password con hash con sale casuale

Aggiunge una cosa significativa. Se rubano il database, hanno il nome utente, la parola saltata per utente e la password con hash. Ma ancora non hanno la password originale. Per invertire l'hash, generalmente dovranno fare una quantità significativa di lavoro separato per ciascun utente.

Senza qualsiasi sale (una pessima idea, come appreso da LinkedIn), gli attaccanti possono usare preesistente tavole arcobaleno e non hanno lavoro per utente per gli hash che traggono vantaggio dalle tabelle. Anche se nessuna parte dell'hash è nella tabella, possono raggruppare il lavoro (ad esempio se un utente ha due account con la stessa password oscura).

Con un sale per sito, possono generare una tabella arcobaleno per il sito e continuare a condividere il lavoro tra gli utenti.

Ricorda che se incrinano la password di un utente, oltre ad essere in grado di accedere al tuo sito, possono probabilmente anche accedere ad altri siti che l'utente utilizza.

Ciò che fa per te è costringerli a generare una tabella arcobaleno per utente invece di una tabella arcobaleno per l'intero sito per decifrare la tua password. Significa anche che non possono semplicemente google i tuoi valori hash, che è la "tavola dell'arcobaleno finale". Cambia la proposta di cracking in un compito molto più difficile.

Google "5f4dcc3b5aa765d61d8327deb882cf99". Guarda cosa ottieni (suggerisci che è l'hash MD5 della password e ci sono migliaia di risultati).

L'hashing di ogni passphrase con un diverso sale è migliore rispetto all'utilizzo di un solo sale, ma un sale è meglio di nessun sale.

Il sale serve a rendere l'elaborazione della password diversa per ogni utente. Altrimenti, l'autore dell'attacco che ha ottenuto una copia del tuo database (memorizzi la password hash proprio perché prevedi questa situazione) potrebbe ottimizzare la sua ricerca e attaccare tutte le password con lo stesso sforzo di quello necessario per rompere un password singola (le tabelle arcobaleno, come qualsiasi altra tabella precalcolata, sono un'incarnazione di questo concetto). Con i sali per utente, almeno, l'attaccante pagherà l'intero sforzo bruto-force per ogni password che desidera crack.

(Idealmente, usi un sale per utente che cambi anche ogni volta che l'utente cambia la sua password. Quindi è davvero un sale per password.)

I sali sono solo metà della storia; vuoi anche che il meccanismo di hashing sia slow (in modo configurabile, ma molto lento). Un semplice hash è troppo veloce, gli attaccanti possono letteralmente calcolarne miliardi al secondo.

Usa bcrypt . Le implementazioni di Bcrypt gestiscono la generazione e l'utilizzo di sale e bcrypt può essere reso lento come richiesto.

Le password di salatura individuale aiutano a prevenire gli attacchi sfruttando un passo di precomputazione non in linea, come i compromessi della memoria temporale (tabelle raibow). Questo costringe l'attaccante a eseguire la forza bruta sugli hash per recuperare una password. Questo post sul blog descrive diverse strategie di archiviazione delle password, dal meno sicuro al più sicuro.

Permettetemi di aggiungere che non volete hash con MD5 o SHA-1. Quelli erano progettati per essere veloci. Qual è l'esatto opposto di quello che vuoi quando qualcuno sta cercando di decifrare la tua lista di password. Hash con bcrypt, progettato per essere lento. Questa è un'opzione che molti sviluppatori ignorano.

Modifica: Ecco un buon articolo a riguardo.

Modifica: Un altro articolo dice che anche PBKDF2 e scrypt sono buone scelte.