Sale non casuale per gli hash delle password

AGGIORNAMENTO: Recentemente ho appreso da questa domanda che nell’intera discussione di seguito, io (e sono sicuro che anche altri lo facevano) era un po ‘confuso: quello che continuo a chiamare un tavolo arcobaleno, in realtà è chiamato tabella hash. I tavoli arcobaleno sono creature più complesse e sono in realtà una variante di Hellman Hash Chains. Anche se credo che la risposta sia sempre la stessa (dal momento che non discende dalla crittanalisi), alcune discussioni potrebbero essere un po ‘distorte.
La domanda: ” Quali sono i tavoli arcobaleno e come vengono utilizzati? ”


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

Ma è in realtà necessario crittograficamente che il sale sia casuale? A questo proposito, qualsiasi valore univoco (univoco per utente, ad esempio userId) è sufficiente? In effetti impedirebbe l’uso di una singola Rainbow Table per violare tutte (o quasi) le password nel sistema …
Ma la mancanza di entropia indebolisce davvero la forza crittografica delle funzioni di hash?


Nota, non sto chiedendo perché usare salt, come proteggerlo (non è necessario che sia), usando un singolo hash costante (non farlo), 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 mi piacerebbe concentrarmi sulle aree con cui sono (poco) meno familiare. Principalmente implicazioni per la crittoanalisi: apprezzerei di più se qualcuno avesse qualche input dal punto di vista criptico-matematico.
Inoltre, se ci sono vettori aggiuntivi che non sono stati considerati, anche questo è un grande input (vedi @Dave Sherohman point su più sistemi).
Oltre a ciò, se avete una teoria, un’idea o una pratica migliore, si prega di eseguire il backup con prove, scenari di attacco o prove empiriche. O anche considerazioni valide per compromessi accettabili … Ho familiarità con Best Practice (capitale B maiuscola P) sull’argomento, mi piacerebbe dimostrare quale valore questo effettivamente fornisce.


EDIT: Alcune risposte davvero buone qui, ma penso che come dice @Dave, si arriva a Rainbow Tables per nomi utente comuni … e possibili nomi meno comuni. Tuttavia, cosa succede se i miei nomi utente sono globalmente unici? Non necessariamente univoco per il mio sistema, ma per ogni utente, ad es. Indirizzo email.
Non ci sarebbe alcun incentivo a build un RT per un singolo utente (come sottolineato da @Dave, il sale non è tenuto segreto), e ciò impedirebbe ancora il clustering. Unico problema sarebbe che potrei avere la stessa email e password su un altro sito, ma Salt non lo impedirebbe comunque.
Quindi, ritorna alla crittanalisi: l’entropia è necessaria o no? (Il mio pensiero corrente è che non è necessario da un punto di vista della crittanalisi, ma è da altri motivi pratici.)

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

Tuttavia, l’utilizzo del nome utente o di qualsiasi altro valore controllato dall’utente come sale ridurrebbe la sicurezza tra i sistemi, poiché un utente che aveva lo stesso nome utente e password su più sistemi che utilizza lo stesso algoritmo di hashing della password finirebbe con lo stesso hash della password ciascuno di questi sistemi. Non ritengo che ciò sia una responsabilità significativa perché, in qualità di 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 più facile l’attacco vero e proprio. (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 riuserà le password.)

Il pericolo maggiore derivante da questa idea è che i nomi utente vengono comunemente riutilizzati: praticamente qualsiasi sito che si desidera visitare avrà un account utente denominato “Dave”, ad esempio, e “admin” o “root” sono ancora più comuni – il che renderebbe la costruzione di tabelle arcobaleno indirizzate agli utenti con questi nomi comuni molto più semplici ed efficaci.

Entrambi questi difetti potrebbero essere risolti efficacemente aggiungendo un secondo valore di sale (fisso e nascosto o esposto come il sale standard) alla password prima di eseguirne l’hashing, ma, a quel punto, si potrebbe anche usare il sale entropico standard in ogni caso di lavorare il nome utente in esso.

A cura di aggiungere: Molte persone parlano di entropia e se l’entropia nel sale è importante. Lo è, ma non per la ragione per cui la maggior parte dei commenti su di esso sembrano pensare.

Il pensiero generale sembra essere che l’entropia è importante in modo che il sale sia difficile da indovinare per un attaccante. Questo non è corretto e, di fatto, completamente irrilevante. Come è stato sottolineato alcune volte da varie persone, gli attacchi che saranno influenzati da sale possono essere fatti solo da qualcuno con il database delle password e qualcuno con il database delle password può solo guardare per vedere qual è il sale di ogni account. Indipendentemente dal fatto che sia ipotizzabile o meno, non importa quando puoi banalmente cercarlo.

La ragione per cui l’entropia è importante è evitare il raggruppamento dei valori del sale. Se il sale è basato sul nome utente e sai che molti sistemi avranno un account chiamato “root” o “admin”, allora puoi creare una tabella arcobaleno per quei due sali e questo creerà la maggior parte dei sistemi. Se, d’altra parte, viene usato un sale casuale a 16 bit e i valori casuali hanno una distribuzione pressoché uniforms, allora hai bisogno di una tabella arcobaleno per tutti i 2 ^ 16 possibili sali.

Non si tratta di impedire all’aggressore di sapere quale sia il sale di un account individuale, si tratta di non dare loro il grande, grasso objective di un singolo sale che verrà utilizzato su una parte sostanziale dei potenziali bersagli.

Usare un sale ad alta entropia è assolutamente necessario per conservare le password in modo sicuro.

Prendi il mio nome utente “gs” e aggiungilo alla mia password “MyPassword” dà gsMyPassword. Questo può essere facilmente rotto usando un rainbow-table perché se il nome utente non ha abbastanza entropia potrebbe essere che questo valore sia già memorizzato nella rainbow-table, specialmente se il nome utente è breve.

Un altro problema sono gli attacchi in cui si sa che un utente partecipa a due o più servizi. Esistono molti nomi utente comuni, probabilmente i più importanti sono admin e root. Se qualcuno creava un tavolo arcobaleno con sali con i nomi utente più comuni, poteva usarli per compromettere gli account.

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

Ho trovato questo correttore di password che risolve l’entropia della tua password. Avere entropia più piccola nelle password (come usare i nomi utente) rende molto più facile per le tabelle di arcobaleno mentre cercano di coprire almeno tutte le password con bassa entropia, perché è più probabile che si verifichino.

È vero che il nome utente da solo potrebbe essere problematico in quanto le persone potrebbero condividere nomi utente tra diversi siti web. Ma dovrebbe essere piuttosto problematico se gli utenti avessero un nome diverso su ciascun sito web. Quindi, perché non renderlo unico su ogni sito web. Hash la password in qualche modo come questo

hashfunction ( “www.yourpage.com /” + nomeutente + “/” + password)

Questo dovrebbe risolvere il problema. Non sono un maestro della crittanalisi, ma dubito che il fatto che non usiamo un’alta entropia renderebbe l’hash più debole.

Mi piace usare entrambi: un sale per record da random ad alta entropia, oltre all’ID univoco del record stesso.

Anche se questo non aggiunge molto alla sicurezza contro gli attacchi del dizionario, ecc., Rimuove il caso marginale in cui qualcuno copia il proprio sale e hash in 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 posso vedere alcun danno nelle cinture e nelle parentesi graffe quando si tratta di sicurezza.)

Se il sale è noto o facilmente ipotizzabile, non hai aumentato la difficoltà di un attacco di dizionario. Potrebbe persino essere ansible creare una tabella arcobaleno modificata che tenga conto di un sale “costante”.

L’utilizzo di sali unici aumenta la difficoltà degli attacchi del dizionario BULK.

Avere un valore di sale unico, crittograficamente forte sarebbe l’ideale.

Direi che finché il sale è diverso per ogni password, probabilmente starai bene. Il punto di sale, è che non è ansible utilizzare la tabella arcobaleno standard per risolvere ogni password nel database. Quindi, se si applica un diverso salt a ogni password (anche se non è casuale), l’utente malintenzionato dovrebbe fondamentalmente calcolare una nuova tabella arcobaleno per ogni password, dal momento che ogni password utilizza un sale diverso.

L’utilizzo di un sale con più entropia non aiuta molto, poiché si presuppone che l’autore dell’attacco in questo caso abbia già il database. Dal momento che devi essere in grado di ricreare l’hash, devi sapere già che cos’è il sale. Quindi è necessario memorizzare il sale, o comunque i valori che compongono il sale nel file. In sistemi come Linux, il metodo per ottenere il sale è noto, quindi non è utile 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’utilizzo di un sale noto all’attaccante rende ovviamente più attraente la costruzione di una tabella arcobaleno (in particolare per i nomi utente hard-coded come root ), ma non indebolisce l’ hash . L’uso di un sale sconosciuto all’attaccante 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 usare una parola salt di una serie di caratteri pseudo-casuali, memorizzata con la password hash è probabilmente un’idea migliore. A titolo illustrativo, se avessi username “potato” e password “beer”, l’input concatenato per il tuo hash è “potatobeer”, che è una voce ragionevole per un tavolo arcobaleno.

Cambiare il sale ogni volta che l’utente cambia la propria password potrebbe aiutare a sconfiggere gli attacchi prolungati, così come l’applicazione di una politica di password ragionevole, ad esempio caso misto, punteggiatura, lunghezza minima, modifica dopo n settimane.

Tuttavia, direi che la scelta dell’algoritmo di digerire è più importante. L’uso di SHA-512 sta dimostrando di essere più un problema per qualcuno che genera una tabella arcobaleno rispetto a MD5, ad esempio.

Il sale dovrebbe avere il maggior numero ansible di entropia per garantire che se un determinato valore di input venga sottoposto a hashing più volte, il valore hash risultante sarà il più vicino ansible, sempre diverso.

L’utilizzo di valori salina mutevoli con la massima entropia ansible nel sale garantirà che la probabilità di hashing (ad esempio, password + sale) produrrà valori hash completamente diversi.

Minore entropia nel sale, maggiore è la possibilità che tu abbia di generare lo stesso valore di sale, quindi maggiori sono le possibilità che tu abbia di generare lo stesso valore di hash.

È la natura del valore hash essere “costante” quando l’input è noto e “costante” che consente agli attacchi del dizionario o alle tabelle arcobaleno di essere così efficaci. Variando il valore dell’hash risultante il più ansible (utilizzando valori di sale entropici elevati) assicura che l’hashing dello stesso input + salt random produca molti risultati di hash diversi, con conseguente riduzione (o almeno una riduzione significativa dell’efficacia) della tabella arcobaleno attacchi.

L’entropia è il punto del valore del sale.

Se dietro al sale c’è una “matematica” semplice e riproducibile, è come se il sale non fosse lì. Aggiungere solo il valore temporale dovrebbe andare bene.