Quali sono i demeriti di un sale derivato per l'archiviazione delle password?

Il motivo per aggiungere un po 'di sale a una password prima di eseguirne l'hashing, è rendere molto più difficile invertire l'hashing. Quindi un numero completamente casuale è la soluzione migliore.

Dovendo inventare un numero di "derivato salato" che è abbastanza unico in modo che la maggior parte delle tue password utente abbia un hash diverso sarà difficile. Quando si genera un numero di sale abbastanza grande (16 byte, ad esempio) sarà probabilmente unico per tutti gli utenti che creeranno mai un account sul proprio sistema senza molto duro lavoro da parte dell'utente per determinare l'unicità.

Inoltre, l'utilizzo di un parametro come l'indirizzo email dell'utente può essere complicato. Se desiderano modificare il proprio indirizzo email, perdono il "sale derivato" a meno che non si costringa l'utente a cambiare la password nello stesso momento in cui cambiano il proprio indirizzo email (o qualsiasi altro parametro utente utilizzato nel calcolo del proprio "sale derivato" .) In ogni caso, vorresti sicuramente salvare il sale nel database per assicurarti di poter sempre confrontare le password sui futuri account di accesso.

Non penso che un sale derivato unico sia peggio di un sale unico a caso. L'unico scopo di un sale è confondere la scoperta delle password quando si ottiene la tabella degli hash.

Affinché una password venga scoperta da un hash, deve essere alquanto ipotetica nel senso che è stata trovata in una tabella arcobaleno esistente o (ad esempio) identica a un'altra password nel set di dati.

+--------------------------------------------------+
|    password   |               hash               |
+---------------+----------------------------------+
| freaky        | 33ca4223307e2fa4fd77c394ceb4e37b |
| freaky        | 33ca4223307e2fa4fd77c394ceb4e37b | <- identical to previous
| Freaky Friday | 852d2f614f08a63911f8944df6df40df |
| ...

Che cosa ho in mente, permettimi di rideterminare lo scopo con un ulteriore grana di precisione:

L'unico scopo di un salt è quello di confondere la scoperta delle password facilmente ipotizzabili quando si ottiene la tabella degli hash.

Anche il peggior sale possibile supporta questo obiettivo abbastanza bene. Diciamo per argomento che dovevo salare ogni riga con gli 8 byte prevedibili e piuttosto ovvi " Salted__ " (osservando, per favore non farlo).

In Crackstation.net oggi non trovo nemmeno " Salted__123456 ", quindi presumibilmente l'autore dell'attacco dovrebbe identificare o creare una tabella arcobaleno personalizzata prima di poter iniziare l'attacco. Ma nota, password deboli come " freaky " avrebbero ancora lo stesso hash e quindi sarebbero ancora un focus iniziale per l'attacker per provare le "top X password" o qualsiasi altra cosa. E una volta creata la tabella arcobaleno, l'attacco potrebbe continuare per l'intero set di dati.

La prossima scelta più potente di sale, quindi, sarebbe unica per riga. Ciò significherebbe che l'utente malintenzionato dovrebbe creare una nuova tabella arcobaleno per ciascuna password. Questo significa che se l'attaccante è solo dopo uno dei tuoi utenti, lo sforzo è lo stesso del sale statico sopra. Ma, se l'attaccante vuole il tuo intero tavolo, la complessità temporale del cracking è aumentata.

Non credo che faccia la differenza se il sale sia unico e casuale; o semplicemente unico.

Immagina di essere l'attaccante e di avere gli hash. Sai che dovrai costruire un tavolo arcobaleno per attaccare ogni fila. Ha importanza quali sono i valori del sale? Se si vede il valore di sale unico nella tabella hash; o se sai che il sale è customer_id o qualsiasi altra cosa, non cambia la quantità di lavoro che devi fare.

Quindi immagina di essere l'attaccante e NON hai gli hash. Cosa succede se hai appreso che le password vengono salate con l'ID cliente? Immagino che questo significhi che potresti precomputare tutte le tabelle arcobaleno prima di effettuare un furto degli hash, ma questo non diminuisce la parte difficile del tuo carico di lavoro, quindi direi che è insignificante.

Il punto principale per aggiungere sale è aumentare l'entropia della password. Questo per proteggere dal potenziale per chiunque di creare tabelle arcobaleno predefinite di un ampio set di password per decifrare le password.

Il modo più semplice e diretto per farlo è semplicemente generare un numero casuale. Puoi generare tutta l'entropia che vuoi. È un design semplice, facile da implementare e difficile da rovinare.

Scegliere alcuni dettagli casuali di un utente e usarlo come sale derivato è sia più complicato che facile da rovinare. Lo schema che hai creato fornisce in realtà ULTERIORI informazioni sulla password, rendendo più facile il crack. L'indirizzo email è noto, la password no. Ma dal momento che stai fornendo la somma dei valori della password nel sale, ora c'è un semplice controllo preliminare prima di provare l'hash. Prima di tentare di cancellare la password (dovrebbe essere lenta) basta sommare la password (tentata) e confrontarla con la somma nel sale memorizzato. Se non corrisponde, prova un altro. Questo può aumentare i tentativi di indovinare in modo GRANDE, dal momento che sommare la potenziale password è MOLTO MOLTO più veloce dell'astinatura.

Ovviamente è risolvibile con un design diverso, ma il punto è che la progettazione della sicurezza è HARD, ed è per questo che normalmente dovresti adottare soluzioni ben accettate per conto tuo. È molto meno probabile che ricada in trappole ben note in questo modo.