bcrypt: sale casuale vs sale calcolato

Non vuoi usare un sale fisso per un dato utente perché potrebbe portare al riutilizzo del sale, che è male (è il peccato capitale dei sali, poiché l'intera idea dei sali non deve essere riutilizzata, non hanno altra funzione). Il riutilizzo del sale può verificarsi, praticamente, per i seguenti due motivi:

• Se un utente cambia la sua password, la nuova password utilizzerà lo stesso sale del vecchio. È sbagliato, perché le vecchie password sono ancora valide (dal momento che gli utenti riutilizzano le password, la vecchia password può essere la password che l'utente imposterà il mese prossimo, ma può anche essere la password per lo stesso utente su un altro sito) e il riutilizzo consentirà l'attaccante ad attaccare sia la vecchia che la nuova password per il costo di una forza bruta.

• Se il sale è derivato dal nome utente, allora un'altra istanza del software server, su un server distinto, può finire con gli stessi sali, perché "Amministratore" tende a sempre essere chiamato "Amministratore". Gli aggressori potrebbero precomporre una tabella di grandi dimensioni (ad esempio una tabella arcobaleno) per "Amministratore", applicabile a molti siti (il che renderebbe la creazione di tabelle utile per lo sforzo).

Solitamente riassumo ciò affermando che i sali devono essere unici tempo (nessun riutilizzo di un vecchio valore salino) e mondiale (nessun riutilizzo di sali da nessuna parte, anche su un server distinto). Tale unicità è difficile da ottenere, ma c'è comunque un modo piuttosto semplice, che è quello di generare sali abbastanza grandi (ad esempio, i sali di 128 bit, come bcrypt usa) a caso.

Riepilogo: non generare in modo casuale i sali di bcrypt non sarebbe più sicuro; al massimo, questo sarebbe ugualmente sicuro, ma, più probabilmente, meno sicuro.

Il motivo di un sale è, per prevenire attacchi con tabelle arcobaleno precalcolate. L'utente malintenzionato dovrebbe creare una tabella arcobaleno per ciascuna password, e ciò non ha senso (è più facile eseguire la forza bruta fino a quando non si trova una corrispondenza). Quindi il lavoro di sale è fatto, anche quando è visibile in chiaro nel valore hash.

Se vuoi aggiungere un segreto al calcolo, puoi aggiungere un ulteriore pepe . In contrasto con il sale, il pepe non può essere memorizzato nel database. Questo aiuterà contro gli attacchi del dizionario, purché l'autore dell'attacco abbia solo accesso ai tuoi dati (ad esempio SQL-Injection) ma non al tuo codice.

Non mischiare sale e pepe, perché servono a uno scopo diverso. E per rispondere alla tua domanda, usa un sale casuale e aggiungi un peperone se vuoi aggiungere qualcosa di nascosto.

Il sale in bcrypt è lungo 128 bit e generato in modo casuale, quindi avresti bisogno di 2 ^ 127 utenti prima che ci fosse il 50% di possibilità di collisione. Mettiamola in prospettiva: ogni persona sulla terra potrebbe creare un account utente per ogni atomo nel proprio corpo, e saremmo comunque solo a circa 1/3 del percorso.

Usa il sale casuale. Le soluzioni che coinvolgono i sali calcolati introducono alcuni problemi delicati che possono alla fine portare alla differenza tra una seccatura e una catastrofe.