Dato che sto tagliando tutte le password con il loro sale, c'è un vantaggio per il fatto che il sale sia davvero casuale, o un contatore incrementale o un guid sia abbastanza buono? Inoltre, c'è un vantaggio di avere un sale più grande rispetto a un sale più piccolo?
Modifica Poiché è stabilito che gli hash non dovrebbero essere troppo piccoli: qual è una dimensione sufficiente di un sale? Sarà un guid (16 byte)?
Lo scopo unico di sale è univoco : nessuna password con hash deve utilizzare lo stesso valore di sale. Questo ha lo scopo di prevenire la condivisione dei costi come le tabelle hash precalcolate.
L'unicità dovrebbe essere in tutto il mondo . Ad esempio, supponiamo di aver usato un semplice contatore come un sale. Corrispondentemente, il valore "1" sarà usato come sale per il primo account creato, presumibilmente quello per l'amministratore del server. Questo vale per le tutte istanze installate di quel server. Ciò rende utile precomputare un grande tavolo (ad esempio una tavola dell'arcobaleno ) di potenziali password con hash che usano "1" come sale, perché quella tabella potrebbe essere utilizzata per attaccare la password dell'amministratore su tutti i server che utilizzano quel software. La parola per meditare qui è "utile".
Poiché l'unicità di server non è sufficiente, un contatore non sarà sufficiente; Il nome utente non è un buon sale (i nomi utente sono unici su un determinato server, ma ci sono molti "Bob", "Joe" e "DarkLord42" là fuori). Un UUID (GUID) dovrebbe fare il trucco. Puoi anche usare un generatore pseudocasuale uniforme ( /dev/urandom , CryptGenRandom() , java.security.SecureRandom ... a seconda della piattaforma che usi) e ottenere abbastanza byte casuali da esso in modo che i rischi di riutilizzare un valore di sale siano sufficientemente piccoli; 16 byte sono sufficienti per quello. L'uso della casualità è il "modo robusto" perché produce unicità con una probabilità sufficientemente alta, senza dover fare affidamento su convenzioni mondiali.
Grazie al commento di Hendrik alla domanda, ho trovato una discussione relativa a questo. Ecco i miei risultati:
Se tutti (o almeno diversi) hanno utilizzato lo stesso insieme di sali (ad esempio numeri incrementali o sali brevi), è possibile creare una tabella arcobaleno per tutti i sali ripetuti, rendendo meno sicuri gli hash salati.
Quindi il sale dovrebbe preferibilmente anche essere unico tra i sistemi e non solo all'interno del mio sistema per evitare che un set di tabelle arcobaleno venga creato e utilizzato per compromettere diversi sistemi. (Una tabella per sale = 1, una per sale = 2, una per sale = 3 e così via.)
Non è necessario che un sale sia casuale o segreto. Serve solo a fermare gli attacchi usando per es. tavoli arcobaleno, o rendere tale attacco molto più lento. Se non sbaglio, dovrebbe essere sicuro di inserire una password utente con il suo nome utente.