Salt non casuale per gli hash delle password

AGGIORNAMENTO: Recentemente ho imparato da questa domanda che nell'intera discussione qui sotto, io (e sono sicuro che anche altri lo hanno fatto) ero un po 'confuso: quello che continuo a chiamare un tavolo arcobaleno, in realtà è chiamato tabella hash. I tavoli arcobaleno sono creature più complesse e in realtà sono una variante di Hellman Hash Chains. Anche se credo che la risposta sia sempre la stessa (dal momento che non si riduce alla crittoanalisi), alcune delle discussioni potrebbero essere un po 'distorte.
La domanda: " Cosa sono le tabelle arcobaleno e come vengono utilizzate? "

In genere, consiglio sempre di utilizzare un valore casuale crittograficamente forte come salt, da utilizzare con funzioni hash (ad esempio per le password), come per proteggere dagli attacchi di Rainbow Table.

Ma è davvero necessario crittograficamente che il sale sia casuale? Qualunque valore univoco (univoco per utente, ad es. UserId) sarebbe sufficiente a questo proposito? In effetti, impedirebbe di utilizzare una sola Rainbow Table per decifrare tutte (o la maggior parte) le password nel sistema ...
Ma la mancanza di entropia indebolisce davvero la forza crittografica delle funzioni hash?

Nota, non sto chiedendo perché usare il sale, come proteggerlo (non è necessario), usando un singolo hash costante (non) o che tipo di funzione hash usare.
Solo se il sale ha bisogno di entropia o meno.

Grazie a tutti per le risposte finora, ma vorrei concentrarmi sulle aree che conosco (un po ') meno. Principalmente implicazioni per la crittoanalisi: apprezzerei di più se qualcuno avesse qualche input dal PoV cripto-matematico.
Inoltre, se ci sono vettori aggiuntivi che non sono stati considerati, anche questo è un ottimo input (vedi il punto @Dave Sherohman su più sistemi).
Oltre a ciò, se hai una teoria, un'idea o una buona pratica, ti preghiamo di supportarla con prove, scenari di attacco o prove empiriche. O anche valide considerazioni per compromessi accettabili ... Ho familiarità con Best Practice (B maiuscola P maiuscola) sull'argomento, vorrei dimostrare quale valore effettivamente fornisce.

EDIT: Alcune risposte davvero buone qui, ma penso che come dice @Dave, si tratta di Rainbow Tables per nomi utente comuni ... e anche possibili nomi meno comuni. Tuttavia, cosa succede se i miei nomi utente sono unici al mondo? Non necessariamente univoco per il mio sistema, ma per ogni utente, ad esempio indirizzo e-mail.
Non ci sarebbe alcun incentivo a costruire un RT per un singolo utente (come ha sottolineato @Dave, il sale non è tenuto segreto) e ciò impedirebbe comunque il raggruppamento. L'unico problema sarebbe che potrei avere la stessa email e password su un sito diverso, ma il sale non lo impedirebbe comunque.
Quindi, si torna alla crittoanalisi: l'entropia è necessaria o no? (Il mio pensiero attuale è che non è necessario dal punto di vista della crittoanalisi, ma è per altri motivi pratici.)

Il sale viene tradizionalmente memorizzato come prefisso alla password con hash. Questo lo rende già noto a qualsiasi utente malintenzionato con accesso all'hash della password. L'uso del nome utente come salt o meno non influisce su tale conoscenza e, quindi, non avrebbe alcun effetto sulla sicurezza del singolo sistema.

Tuttavia, l'utilizzo del nome utente o di qualsiasi altro valore controllato dall'utente come salt ridurrebbe la sicurezza tra sistemi, poiché un utente che aveva lo stesso nome utente e password su più sistemi che utilizzano lo stesso algoritmo di hashing della password finirebbe con lo stesso hash della password su ciascuno di questi sistemi. Non lo considero una responsabilità significativa perché io, in quanto utente malintenzionato, proverei le password che un account di destinazione è noto per aver utilizzato su altri sistemi prima di tentare qualsiasi altro mezzo per compromettere l'account. Gli hash identici mi direbbero solo in anticipo che la password conosciuta funzionerebbe, non renderebbero l'attacco effettivo più semplice. (Si noti, tuttavia, che un rapido confronto dei database degli account fornirebbe un elenco di obiettivi con priorità più alta, poiché mi direbbe chi è e chi non sta riutilizzando le password.)

Il pericolo maggiore derivante da questa idea è che i nomi utente vengono comunemente riutilizzati: quasi tutti i siti che desideri visitare avranno un account utente denominato "Dave", ad esempio, e "admin" o "root" sono ancora più comuni - il che renderebbe costruzione di tabelle arcobaleno mirate agli utenti con quei nomi comuni molto più semplice ed efficace.

Entrambi questi difetti potrebbero essere efficacemente risolti aggiungendo un secondo valore di sale (fisso e nascosto o esposto come il sale standard) alla password prima dell'hashing, ma, a quel punto, potresti anche usare comunque il sale entropico standard. di inserire il nome utente in esso.

Modificato per aggiungere: molte persone parlano di entropia e se l'entropia nel sale è importante. Lo è, ma non per il motivo che la maggior parte dei commenti sembra pensare.

Il pensiero generale sembra essere che l'entropia è importante in modo che il sale sarà difficile da indovinare per un attaccante. Questo non è corretto e, in effetti, del tutto irrilevante. Come è stato sottolineato più volte da varie persone, gli attacchi che saranno influenzati dal sale possono essere effettuati solo da qualcuno con il database delle password e qualcuno con il database delle password può semplicemente guardare per vedere qual è il sale di ogni account. Che sia indovinabile o meno, non importa quando puoi banalmente cercarlo.

Il motivo per cui l'entropia è importante è evitare il raggruppamento dei valori del sale. Se il sale è basato sul nome utente e sai che la maggior parte dei sistemi avrà un account denominato "root" o "admin", puoi creare una tabella arcobaleno per quei due sali e creerà un crack per la maggior parte dei sistemi. Se, d'altra parte, viene utilizzato un sale casuale a 16 bit ei valori casuali hanno una distribuzione approssimativamente uniforme, è necessaria una tabella arcobaleno per tutti i 2 ^ 16 sali possibili.

Non si tratta di impedire all'aggressore di sapere cos'è il sale di un account individuale, si tratta di non dargli l'obiettivo grande e grasso di un singolo sale che verrà utilizzato su una percentuale sostanziale di potenziali bersagli.

L'uso di un sale ad alta entropia è assolutamente necessario per memorizzare le password in modo sicuro.

Prendi il mio nome utente "gs" e aggiungilo alla mia password "MyPassword" fornisce gsMyPassword. Questo è facilmente risolvibile usando una tabella arcobaleno perché se il nome utente non ha abbastanza entropia potrebbe essere che questo valore sia già memorizzato nella tabella arcobaleno, specialmente se il nome utente è breve.

Un altro problema sono gli attacchi in cui sai che un utente partecipa a due o più servizi. Esistono molti nomi utente comuni, probabilmente i più importanti sono admin e root. Se qualcuno creasse una tabella arcobaleno con sali con i nomi utente più comuni, potrebbe usarli per compromettere gli account.

Avevano un sale da 12 bit . 12 bit sono 4096 combinazioni diverse. Non era abbastanza sicuro perché oggi molte informazioni possono essere facilmente archiviate . Lo stesso vale per i 4096 nomi utente più utilizzati. È probabile che alcuni dei tuoi utenti sceglieranno un nome utente che appartiene ai nomi utente più comuni.

Ho trovato questo verificatore di password che calcola l'entropia della tua password. Avere una minore entropia nelle password (come usando i nomi utente) rende molto più facile per le tabelle arcobaleno poiché cercano di coprire almeno tutte le password con bassa entropia, perché è più probabile che si verifichino.

È vero che il nome utente da solo può essere problematico poiché le persone possono condividere nomi utente tra diversi siti Web. Ma non dovrebbe essere problematico se gli utenti avessero un nome diverso su ogni sito web. Allora perché non renderlo unico su ogni sito web. Hash la password in qualche modo in questo modo

funzione hash ("www.yourpage.com /" + nome utente + "/" + password)

Questo dovrebbe risolvere il problema. Non sono un maestro della crittoanalisi, ma dubito che il fatto che non usiamo un'entropia elevata renderebbe l'hashish più debole.

Mi piace usare entrambi: un sale casuale per record ad alta entropia, più l'ID univoco del record stesso.

Anche se questo non aggiunge molto alla sicurezza contro gli attacchi al dizionario, ecc., Rimuove il caso marginale in cui qualcuno copia il proprio salt e hash su un altro record con l'intenzione di sostituire la password con la propria.

(Certo, è difficile pensare a una circostanza in cui ciò si applica, ma non vedo alcun danno in cinture e bretelle quando si tratta di sicurezza.)

Se il sale è noto o facilmente indovinabile, non hai aumentato la difficoltà di un attacco del dizionario. Potrebbe anche essere possibile creare una tabella arcobaleno modificata che tenga conto di un sale "costante".

L'uso di sali unici aumenta la difficoltà degli attacchi del dizionario BULK.

Avere un valore del sale unico e crittograficamente forte sarebbe l'ideale.

Direi che fintanto che il sale è diverso per ogni password, probabilmente starai bene. Il punto del sale, è che non è possibile utilizzare la tabella arcobaleno standard per risolvere ogni password nel database. Quindi, se applichi un salt diverso a ogni password (anche se non è casuale), l'aggressore dovrebbe fondamentalmente calcolare una nuova tabella arcobaleno per ogni password, poiché ogni password utilizza un salt diverso.

Usare un sale con più entropia non aiuta molto, perché in questo caso si presume che l'aggressore abbia già il database. Dato che devi essere in grado di ricreare l'hashish, devi già sapere cos'è il sale. Quindi devi memorizzare il sale, oi valori che compongono il sale comunque nel tuo file. In sistemi come Linux, il metodo per ottenere il sale è noto, quindi non serve avere un sale segreto. Devi presumere che l'attaccante che ha i tuoi valori hash, probabilmente conosce anche i tuoi valori di sale.

La forza di una funzione hash non è determinata dal suo input!

L'uso di un sale noto all'attaccante ovviamente rende la costruzione di una tabella arcobaleno (in particolare per i nomi utente hard-coded come root ) più attraente, ma non indebolisce l' hash . L'utilizzo di un sale sconosciuto all'aggressore renderà il sistema più difficile da attaccare.

La concatenazione di un nome utente e una password potrebbe ancora fornire una voce per una tabella arcobaleno intelligente, quindi utilizzare un sale di una serie di caratteri pseudo-casuali, archiviati con la password con hash è probabilmente un'idea migliore. Ad esempio, se avessi il nome utente "potato" e la password "beer", l'input concatenato per il tuo hash è "potatobeer", che è una voce ragionevole per una tabella arcobaleno.

Cambiare il sale ogni volta che l'utente cambia la password potrebbe aiutare a sconfiggere attacchi prolungati, così come l'applicazione di una politica ragionevole per la password, ad esempio maiuscole / minuscole, punteggiatura, lunghezza minima, modifica dopo n settimane.

Tuttavia, direi che la tua scelta dell'algoritmo digest è più importante. L'uso di SHA-512 si rivelerà più doloroso per qualcuno che genera una tabella arcobaleno rispetto all'MD5, ad esempio.

Il sale dovrebbe avere quanta più entropia possibile per garantire che se un dato valore di input viene sottoposto ad hashing più volte, il valore hash risultante sarà, il più vicino possibile, sempre diverso.

L'uso di valori di sale in continua evoluzione con quanta più entropia possibile nel sale assicurerà che la probabilità di hashing (ad esempio, password + salt) produrrà valori di hash completamente diversi.

Meno entropia nel sale, più possibilità hai di generare lo stesso valore di sale, quindi più possibilità hai di generare lo stesso valore di hash.

È la natura del valore hash essere "costante" quando l'input è noto e "costante" che consente agli attacchi di dizionario o alle tabelle arcobaleno di essere così efficaci. Variando il valore hash risultante il più possibile (utilizzando valori di sale di entropia elevati) assicura che l'hashing dello stesso input + random-salt produrrà molti risultati di valore hash diversi, sconfiggendo (o almeno riducendo notevolmente l'efficacia) della tabella arcobaleno attacchi.

L'entropia è il punto del valore del sale.

Se c'è una "matematica" semplice e riproducibile dietro il sale, allora è lo stesso che il sale non c'è. Basta aggiungere il valore del tempo dovrebbe andare bene.