Nell'hashing, importa quanto sia casuale un sale?

No. Si suppone che un salt sia univoco in modo che non si possa usare un attacco (come le rainbow tables) che calcola un hash della password una sola volta e usa quel risultato contro più hash delle password.

Se sei interessato a rendere reversibile l'hash impossibile senza alcune conoscenze segrete, aggiungi una password specifica del sito alla password fornita (oltre al sale) prima dell'hashing. Un sale è memorizzato con l'hash, quindi renderlo difficile da indovinare è inutile.

@Honoki :
Se è un valore globale o specifico del sito, allora quello a cui stai pensando non è un sale, è qualcos'altro. Questo non vuol dire che non sia una buona idea, ma non è un sale. In genere un segreto specifico dell'installazione è chiamato "chiave del sito" o "password del sito".

Ma i sali sono generalmente memorizzati con l'hash. Ad esempio, ecco l'attuale modo in cui sono salvate le password di accesso Unix / Linux. La password qui è "foobar":

$5$BcjmguyyH.Qrf$ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1

• $ è il delimitatore di campo
• 5 è l'identificatore dell'algoritmo hash (in questo caso SHA-256)
• BcjmguyyH.Qrf è il sale (non mascherato in alcun modo)
• ADRXhi/5xb.dYU67I.JdY57uoFjel/rqMqj14QJmTQ1 è l'hash

Dato che il punto di un sale è impedire a un attaccante di precompilare gli hash, direi che è soprattutto l'unicità del sale che conta, ma la casualità potrebbe essere un fattore per un aggressore particolarmente intraprendente - se i tuoi sali sono molto prevedibile, è ipotizzabile che un utente malintenzionato possa generare tabelle arcobaleno prima di un tentativo di intrusione in modo da accelerare il cracking delle password una volta ottenuto l'hash.

Alcune tecniche sono poco migliori delle password non salate - l'uso di un singolo salt per l'intero database delle password significa che devono calcolare solo un set di hash per decifrare l'intero database e utilizzare i sali derivati in modo prevedibile dai nomi utente (o sono i nome utente effettivo) significa che un utente malintenzionato può precompilare gli hash per gli account degli utenti interessati al cracking (probabilmente i tuoi account amministratore, i dipendenti privilegiati, gli account moderatore, ecc.) anche prima che ottengano una copia del database.

In sintesi i sali devono essere unici e devono essere imprevedibili per la massima sicurezza. Probabilmente non sono necessari standard crittografici di casualità, sebbene siano un buon modo per garantire l'imprevedibilità.

I sali non devono essere unici. Non è un requisito assoluto. Tuttavia, i sali più diversi vengono utilizzati, maggiore è la sicurezza, quindi se possono essere quasi unici è buono, ma non preoccuparti di alcune persone che potenzialmente condividono un sale a causa di una scarsa randomizzazione.

Il sale viene utilizzato per impedire alle persone che utilizzano una tabella arcobaleno pre-preparata di violare le password. Se si utilizza lo stesso sale su ogni password, si è sventato il tavolo arcobaleno già preparato, ma potrebbe essere utile per il pirata informatico creare una tabella arcobaleno personalizzata per le password salate. Se cambi il sale per alcuni utenti, riduci il potenziale guadagno per il cracker nella produzione della sua tavola arcobaleno. Ad esempio, se hai due sali usati in modo casuale, il cracker deve creare due tavoli arcobaleno. Se si usano 50 sali in modo casuale, il cracker deve creare 50 tavoli arcobaleno - ottenere più lavoro. Se si utilizza un sale generato in modo casuale per ciascun utente, il cracker deve ricreare una nuova tabella arcobaleno per ciascun utente. Ora è così tanto lavoro che il cracker non si preoccuperà di provare e userà invece un attacco diverso.

Se hai generato Sali casuali per ogni utente, c'è la possibilità che due o più sali di un utente siano identici. Ciò influirebbe solo marginalmente sulla sicurezza dei siti. Un cracker ora può utilizzare una tabella arcobaleno personalizzata per rompere tutte le password salate identiche. Questo potrebbe essere un attacco praticabile se il numero di utenti con sali identici è abbastanza grande. Se il numero di sali identici è nelle singole cifre, allora non rappresenterebbe un grosso problema.

Il valore del sale non deve essere un segreto. Nascondere il valore del sale è fatto da alcune persone, ma generalmente i sistemi di password tradizionali non lo fanno. Mantenere il sale segreto non offre molta sicurezza aggiuntiva. Lo scopo di Salt è garantire che gli algoritmi delle password non siano simili per ogni utente e quindi bloccare gli attacchi di rainbow table. Conoscere il sale non rende più facile l'incrinatura fino a quando i sali sono quasi unici.

Nella maggior parte degli schemi di hashing delle password, i sali devono essere globalmente unici . Ciò significa che, idealmente, ogni singola istanza di password in tutto il mondo dovrebbe avere il proprio valore di sale, condiviso con nessun altro (in particolare, lo stesso valore di sale non dovrebbe essere usato in due server distinti, e anche il sale deve essere cambiato quando un utente cambia la sua password).

L'unicità globale a livello mondiale è difficile, perché non esiste un repository centrale per i sali allocati. Un modo semplice è fare affidamento su casualità : se generi i tuoi sali da un generatore casuale crittografico strong (cioè un generatore "molto buono") e se fai i tuoi sali abbastanza a lungo, allora la probabilità di un sale la collisione è molto bassa - sufficientemente bassa da essere trascurata. Nota che anche se miriamo all'unicità globale, la collisione occasionale non è immediatamente fatale, quindi possiamo vivere con quel rischio. 16 byte è "abbastanza lungo".

Qualsiasi metodo che garantisce in modo affidabile l'unicità globale è buono; ma la casualità è spesso quella che si adatta meglio, perché è puramente locale (nessun collo di bottiglia a livello di rete).

Mutatis mutandi , questo è lo stesso problema che per UUID . "UUID versione 4" in realtà 122 bit casuali. Tale UUID sarebbe dei sali abbastanza appropriati.