Esistono linee guida o buone pratiche quando si tratta di scegliere la lunghezza dei dati Salt. Ha importanza nello sforzo che un hack deve mettere per abbinare il dizionario (o arcobaleno) alla tabella con l'hash (passoword + salt) memorizzato nel DB.
In parole semplici, c'è una lunghezza ideale di dati Salt. Oppure scegli un sale lungo sopra il sale corto. Perché?
La lunghezza del sale non è importante una volta che ha superato il minimo al di sotto del quale il pre-calcolo diventa economico.
Per citare Wikipedia :
Early Unix implementations limited passwords to 8 characters and used a 12-bit salt, which allowed for 4,096 possible salt values. This was an appropriate balance for 1970s computational and storage costs.
Secondo la mia matematica, un sale a 12 bit significa che qualcuno potrebbe pre-calcolare le tabelle arcobaleno per tutti i 4096 sali; assumendo una password di 7-8 caratteri, tutto ciò che serve è 16 petabyte ... certamente non fuori dalla portata di molti aggressori ben finanziati oggi. I moderni algoritmi crittografici tendono verso sali da 8 a 32 caratteri per alzare il livello ( vedere la tabella 2 qui ) .
Ma credo che la lunghezza del sale non influenzi significativamente la velocità di ogni calcolo della password *. La scelta di un buon algoritmo di password rallenterà i calcoli e ridurrà la velocità con cui un attaccante può montare un attacco di forza bruta; se quell'algoritmo sta ottenendo +8 caratteri di input non farà una differenza significativa rispetto a +16 caratteri o +32.
Quindi finché il sale non è così piccolo da rendere fattibile il precomando, sta facendo la metà del suo lavoro. (L'altra metà è di impedire ad Alice e Bob di avere lo stesso hash se hanno la stessa password).
* Questa è la mia credenza ... ma io non sono un matematico o un cripto codificatore. Prendi questa affermazione con un tocco di, beh, sai ...
Leggi altre domande sui tag passwords hash salt password-cracking