Allungamento di un hash, molte iterazioni rispetto a una stringa di input più lunga

Il motivo principale per cui concatenare il sale e la password molte volte non viene utilizzato è una combinazione di tradizione e pigrizia. Vale a dire, poiché la dimensione della password non è fissa, il numero di copie dovrebbe essere regolato in modo che la dimensione della "stringa molto più lunga" raggiunga un determinato obiettivo. Sembra che alcuni implementatori iniziali di tali schemi lo trovassero macchinosi, probabilmente perché implica l'uso di un'implementazione della funzione hash "in streaming" (che accetta i dati in blocchi successivi) invece di un'implementazione di chiamata con una funzione. La maggior parte dei progettisti più recenti ha semplicemente copiato i disegni precedenti senza alcun motivo valido (né negativo).

Da un punto di vista teorico, più concatenazioni di sale e password sono migliori, perché più iterazioni riducono lo spazio di possibili valori di hash (una funzione di hash non è una permutazione). Ma la riduzione non scende sotto lo spazio 2 ¹²⁸ di una funzione hash a 256 bit, quindi non preoccuparti.

La ragione per "allungare" (iterare) la funzione di hash per scopi di memorizzazione delle password non è quella di rendere un hash più strong, ma semplicemente di rallentare la funzione, con lo scopo di rallentare la forzatura bruta offline e gli attacchi basati sul dizionario.

L'iterazione è solo un modo semplice per ottenerlo, perché i risultati sono facili da capire (1000 iterazioni richiedono circa 1000 volte il tempo necessario). La concatenazione avrebbe un effetto simile, ma sarebbe più difficile capire per quanto tempo la stringa di input dovesse essere necessaria per ottenere un rallentamento simile.