Quando salting e hashing password, qualche vantaggio per includere la lunghezza della password?

Il punto di un sale è che è unico, così che un attaccante che vuole rompere più hash deve fare tutto il lavoro di nuovo per ogni hash. Se includi una caratteristica derivata dalla password, non aiuta il sale. Non fa male, neanche, ma non rafforza il sale in alcun modo.

In effetti, prendendo hash(password+length+salt) invece di hash(password+salt) , stai utilizzando una diversa funzione hash hash2(password+salt) dove hash2(x) = hash(x+length(x)) . Stai effettivamente inventando la tua primitiva crittografica. Questo di per sé è un brutto segno. Non penso che il risultato sia in realtà in qualche modo insicuro, ma lo farei comunque come un rischio inutile.

hash2 è molto più lento di hash . Più lento è buono per un hash della password, ma ci sono modi migliori per rendere l'hash slow - le funzioni di hashing della password hanno un parametro sintonizzabile per configurare la lentezza dell'hash. L'utilizzo di un hash variante non vale la complessità aggiunta.

Il metodo normale per generare il sale è renderlo casuale. Se hai intenzione di aggiungere qualcosa, l'unico punto sarebbe quello di attenuare un bug nel generatore di numeri casuali. Se hai intenzione di farlo, prendi qualcosa che non dipende dalla password, come l'ID utente o l'ora.

Fai attenzione a prendere l'hash di una concatenazione di due stringhe: è ambiguo: hash("bob" + "swordfish") = hash("bobsword" + "fish") . Ogni volta che si prende la concatenazione di alcune stringhe e le si hash o in altro modo le si utilizza in un protocollo crittografico, assicurarsi che le stringhe possano essere scomposte in modo non ambiguo. Se esiste un valore di byte che non può verificarsi in nessuna stringa (i byte null sono spesso adatti), utilizzalo come separatore. Se c'è un limite sulla lunghezza della prima stringa (2 ⁶⁴ è spesso adatto), anteponi la lunghezza (stessa in una codifica a dimensione fissa, ad esempio 8 byte per un 2 ⁶⁴ limite di lunghezza). Se stai costruendo strutture dati complesse, usa il modulo ASN.1 della tua biblioteca.

In ogni caso, quando hai bisogno di memorizzare un hash per le password, non dovresti pensare alla crittografia. Utilizza la libreria bcrypt o PBKDF2 o scrypt del tuo ambiente di programmazione.

Per tutto ciò che volevi sapere sulle password di hashing, su tutto ciò che non volevi sapere sulle password di hashing e su tutto ciò che non sapevi nemmeno di conoscere sulle password di hashing, leggi Come password di hash sicure?

Dipende. Se stai utilizzando un KDF appropriato come PBKDF2 o bcrypt, non c'è alcun vantaggio.

Se utilizzi una semplice funzione di hash crittografica che soffre di attacchi di estensione della lunghezza (ad esempio MD5 o SHA-1 ) quindi può contribuire a ridurre la tua suscettibilità a tali problemi. Tuttavia, a quel punto, hai problemi più grandi.

Non vedo alcun vantaggio (anche se non ci sono svantaggi). Lo scopo della salatura è quello di ostacolare le tabelle hash / tavoli arcobaleno precalcolati, costringendo invece l'attaccante a forzare la forza bruta sugli hash. Se si aggiunge una proprietà facilmente calcolabile della password nel processo di hashing, l'attaccante dovrà solo fare lo stesso (per ogni tentativo di indovinare), e la differenza di tempo sarà trascurabile.

L'output di un buon hash non dovrebbe essere correlato all'input, quindi non si dovrebbe ottenere alcuna casualità addizionale calcolando la lunghezza. Il punto del sale non è quello di rendere l'hash più unico tanto quanto lo è per prevenire la possibilità di precalcolare le tabelle. Poiché la lunghezza di una password indovinata è nota, non aggiunge alcuna protezione contro le tabelle pre-generate.

Ad esempio, se togliamo il sale, testare la password dovrebbe solo sapere quale sia la password8. Non ci sarebbe mai una password3 o una password7. La leggera oscurità dell'algoritmo non ha alcun aumento misurabile della sicurezza.