Quando si utilizzano password di hashing, è corretto usare la password con hash come sale?

Se due utenti hanno la stessa password, allora il sale sarà lo stesso, risultando nello stesso hash per entrambi. Questo non è auspicabile, perché trapelano informazioni sulle password. Se Alice entra nel tuo database e vede che Bob ha lo stesso hash di lei, può usare quelle informazioni. Scegli qualcosa che garantito sia unico.

Il tuo problema più grande qui, però, è che stai usando hash senza alcuna informazione su cosa che hash è. A seconda del sistema, potrebbe anche essere la vecchia implementazione di 3DES che schiaccia tutto dopo l'ottavo carattere. Dovresti utilizzare un KDF appropriato come bcrypt o PBKDF2.

Per rispondere a questo, bisogna capire perché i sali sono necessari in primo luogo. Questo è spiegato abbastanza bene in Come fare in modo sicuro le password di hash? ; ecco un estratto dalla risposta accettata:

Sali : tra i vantaggi dell'attaccante sul difensore, c'è parallelismo . Solitamente l'autore dell'attacco prende un intero elenco di password con hash ed è interessato a spezzarne il maggior numero possibile. Potrebbe provare ad attaccare diversi in parallelo. Ad esempio, l'autore dell'attacco può prendere in considerazione una potenziale password, cancellarla e quindi confrontare il valore con 100 password hash; questo significa che l'attaccante condivide il costo dell'hash su diverse password attaccate. Un'ottimizzazione simile è tabelle precompilate , comprese tabelle arcobaleno ; questo è ancora il parallelismo, con un cambio di coordinate spazio-temporale.

La caratteristica comune di tutti gli attacchi che usano il parallelismo è che funzionano su più password che sono state elaborate con la stessa funzione di hash . Salting riguarda l'utilizzo non della funzione di hash one , ma di molte funzioni hash distinte ; idealmente, ogni istanza di hashing della password dovrebbe utilizzare la propria funzione di hash. Un salt è un modo per selezionare una funzione hash specifica tra una grande famiglia di funzioni hash. I sali applicati correttamente vanificheranno completamente gli attacchi paralleli (incluse le tabelle arcobaleno).

Quindi il problema del tuo sale è che non interferisce con la parallelizzazione rompendo gli hash, che è lo scopo stesso della salatura. Ti consiglio vivamente di leggere la risposta originale , ha ulteriori consigli sulla salatura.

Se si utilizza la password come "salt", non si utilizza affatto del sale; stai solo cancellando la password.

Se due utenti scelgono la stessa password, finiscono con la stessa password con hash. Questo è quello che viene spesso detto come se spiegasse il problema, ma sembra che molte persone sbagliano. Immaginano che questo significhi "collisione", che, per qualche motivo, è considerato da molti come una parolaccia quando si parla di hashing delle password. Ma questo è sbagliato, e non il punto.

Il punto è determinismo . Supponiamo che io, volentieri, prenda una copia delle password hash per 1000 utenti (ad esempio, ho recuperato un vecchio nastro di backup dal bidone della spazzatura). Quindi posso "provare" le potenziali password: ho cancellato una potenziale password (usando la password stessa come "salt") e poi cerco il valore tra i 1000 valori hash. Ciò significa che, pagando il prezzo computazionale dell'hash one , provo effettivamente mille coppie di utenti + password. Sto attaccando un migliaio di password con hash in parallelo, allo stesso costo di un singolo attacco. Questo tipo di parallelismo può esprimersi sotto diverse forme, comprese le tavole arcobaleno.

Lo preferiamo quando attacchi 1000 password hash costano 1000 volte il costo dell'attacco di 1 password hash. Per fare ciò, hai bisogno di veri sali, cioè sali che sono distinti per gli utenti distinti, anche quando capita di usare la stessa password - e, in realtà, quando potenzialmente usano la stessa password. Quando non c'è un vero sale, l'attacco parallelo non funziona perché alcuni utenti scelgono la stessa password, ma poiché se avevano scelto la stessa password allora avrebbero ottenuto il stesso valore hash. In realtà non hanno bisogno di scegliere la stessa password per innescare la debolezza.

Usare il nome utente come sale è molto meglio. Non va bene, attenzione! ma ancora meglio. Ciò che è ancora meglio, al punto di essere effettivamente decentemente sicuro, è usare sali casuali.

Usare un nome utente o una password come sale non mi sembra una buona idea.

Un utente malintenzionato potrebbe ragionevolmente supporre che stai utilizzando il nome utente o la password come sale. A seconda della configurazione, potrebbe essere molto ragionevole supporre che un utente malintenzionato possa ottenere l'accesso ai nomi utente.

Inoltre, a seconda di quanto sia rigoroso il tuo sistema nel far rispettare le password, l'utente malintenzionato potrebbe sfruttare le password che appaiono in un dizionario di password conosciute / comuni e poiché vengono utilizzate come sale il tuo sistema sarebbe vulnerabile a questo tipo di attacco .

Utilizzare un sale che non si basa sull'input dell'utente è un'idea molto migliore.

Recentemente ci sono stati casi in cui sono stati trapelati oltre 100.000.000 di hash. Speriamo che fossero salati. Penso che un gran numero come questo renda l'effetto della salatura molto più ovvio.

Diciamo che ci sono password che non sono veramente pericolose, ma non abbastanza sicure, perché la possibilità che un utente casuale utilizzi una di queste password è una su 10 miliardi. Se provo solo 100 password di questo tipo, allora posso aspettarmi di indovinare la password di uno di questi 100 milioni di persone. Dato che la password è stata sottoposta a hash, quindi è stata salata nuovamente con hash e hash, posso facilmente capire cosa è memorizzato nel database per ciascuna di queste password, quindi dopo 100 hash ho trovato una password.

Se le password sono state correttamente salate, ognuna con un diverso sale, anche se ogni sale è noto, devo calcolare 10 miliardi di hash per ottenere lo stesso risultato.