La salatura di un hash è davvero sicura come implica la conoscenza comune?

Sei fondamentalmente corretto che sta solo rendendo la password più lunga, ma ci sono alcune cose aggiuntive che aggiunge. Anche la password media non è così lunga o sicura e l'aggiunta di una lunghezza "gratuita" è raramente pessima. Il sale lo fa in modo che un utente malintenzionato non possa hash "password" una volta e quindi cercare ogni utente che ha una password di "password".

Invece, dovrebbero generare hash di "password03j9834nfp-3028n408" e "passwordn0438wnvas89v5sne" e ... Ciò aumenta notevolmente la protezione dell'identificazione delle password non sicure e ha comunque un vantaggio positivo nell'aumentare la difficoltà di trovare password sicure.

Dove la tua comprensione va fuori strada quando dici "Non è possibile che un attaccante costruisca un tavolo arcobaleno, quindi converti tutti gli hash e rimuovi il sale?". Ci sono alcuni problemi qui.

Il primo è quello delle collisioni. Non è garantito che una tabella arcobaleno produca l'input originale, è interessato solo alla produzione di input AN che ha prodotto l'output desiderato. Poiché il sale verrà aggiunto a qualsiasi utente entri, l'utente malintenzionato deve trovare l'input esatto utilizzato per l'hash.

Poiché è necessario trovare l'input esatto, si perde il vantaggio di una tabella arcobaleno di sfruttare collisioni. Inoltre, la dimensione richiesta per forzare la forza bruta di tutti i sali possibili sarebbe troppo grande per quasi tutti gli attaccanti da tenere.

Non puoi semplicemente rimuovere il sale da un hash senza capire quale fosse l'input originale. Dovresti cercare un valore che termina con il sale corrispondente all'hash specificato. Ciò richiede quindi che venga prodotta una tabella arcobaleno separata per ogni valore di sale nel DB e questo annulla la possibilità di pre-calcolare poiché è impossibile creare una tabella arcobaleno per ogni sale possibile.

Hai un malinteso fondamentale su come funzionano le tavole arcobaleno.

Una tabella arcobaleno o una tabella hash viene creata da un utente malintenzionato precedente a un attacco. Supponiamo che io costruisca una tabella hash contenente tutti gli hash di stringhe al di sotto di 7 caratteri per MD5 . Se comprometto il tuo database e ottieni l'elenco degli hash, tutto quello che devo fare è cercare l'hash sulla tabella per ottenere la tua password.

Con un valore salt, non è possibile generare una tabella arcobaleno per un algoritmo specifico precedente a un attacco. Un sale non è pensato per essere segreto, lo memorizzi accanto all'hash nel tuo database.

x = hash(salt+password) Lo memorizzerai quindi nel tuo database nel formato di salt+x Ciò rende inutili le tabelle arcobaleno e le tabelle hash.

Come al solito non fai il tuo, usa bcrypt , scrypt o pbkdf2 che si prende cura di tutti i dettagli inclusa la salatura per te. Vedi Come fare in modo sicuro le password di hash?

Un tavola dell'arcobaleno è un ottimizzazione per invertire gli hash con la forza bruta. Funziona in base a un compromesso: fai molta precomputazione per costruire un'enorme struttura dati e puoi quindi crackare rapidamente molti hash.

Una tabella arcobaleno aiuta solo gli hash crack nello spazio di ricerca che copre. Concretamente, le tabelle arcobaleno sono create per testi in chiaro composti da caratteri stampabili e [fino a una certa lunghezza. Il principio di base di aggiungere un salt è che il testo in chiaro che contiene hash contiene sia la password che il sale; con il sale aggiunto, lo spazio di ricerca diventa troppo grande per costruisci una tabella arcobaleno .

Quindi, aggiungendo un sale alla password, non c'è modo di ammortizzare il costo di un attacco di forza bruta su molte fessure. L'attaccante deve fare tutto il lavoro per ogni hash, iniziando solo quando conosce il sale.

Dato un hash e un sale, non c'è modo di "rimuovere il sale". Questa è una proprietà di base di una funzione hash: anche se sai che due stringhe sono correlate (ad esempio, sapendo che la password è una sottostringa di password + salt), non ti aiuta a trovare hash (password) che conoscono hash (password + sale). Non c'è bisogno di nascondere il sale dall'aggressore : deve essere unico (e non derivato dalla password ) ma non deve essere più segreto dell'hash. (Puoi aggiungere un ulteriore sale segreto, che è chiamato pepe , ma è utile solo in un ristretto insieme di circostanze.)

Salare l'hash è solo metà della battaglia. Un'altra parte delle password di hashing in sicurezza è che la funzione di hash deve essere lenta, perché questo fa molto più male al cracker che al verificatore. Non rollare il tuo , usa un metodo che è stato controllato da esperti. Utilizza bcrypt o PBKDF2 o scrypt . L'implementazione della memorizzazione delle password non dovrebbe implicare l'esecuzione di alcuna crittografia da solo, chiamare una funzione di libreria.

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?

Un unico sale risolve un problema: ogni account non può essere attaccato simultaneamente in un gigantesco tentativo di forza bruta.

Supponiamo che tu abbia provato a costruire una tabella arcobaleno di tutte le password ASCII stampabili di 8 caratteri ¹ . Questo è 96 ⁸ ~ 7,2 milioni di miliardi (7,2 x 10 ¹⁵ ) possibilità. Se avessi una GPU che genera password a un miliardo di euro al secondo, ci vorranno circa un mese per crackare (e a 200 W a $ 0,10 per kWh è di circa $ 200 in media; ~ $ 400 peggiore per la tua bolletta elettrica).

Quindi scopri gli hash di ogni account su linkedin da una sorta di SQL injection o di trovare un hard disk con un vecchio backup. Hai hash di un milione di utenti. Ora se sono degli hash non salati, puoi rompere la stragrande maggioranza di questi hash in due mesi con una GPU per circa ~ $ 400 di elettricità. Se sono tutti salati in modo univoco e si desidera rompere tutti i milioni di loro, ora ci vorranno $ 400 milioni di dollari di elettricità poiché ogni sale unico deve avere il proprio attacco indipendente. Ora prima che tu dica, costruirò un tavolo arcobaleno più grande che include i sali, rendi conto che almeno un tipico sale ha 5 caratteri esadecimali (16 ** 5), il che significa che ci vorrà un milione di volte di più per creare il tuo arcobaleno tabella (ad esempio, dovrai spendere $ 400 milioni sull'elettricità per generarlo).

Ora aggiungi il rafforzamento della chiave dove invece di fare un hash una volta, itererai il processo N volte (ad es., una funzione hash ripetuta per tre volte sarebbe: hash(salt+hash(salt+hash(salt+pw))) ). Ora invece di essere in grado di rompere un miliardo di hash al secondo, possono rompere un miliardo / N di hash al secondo, quindi tutti gli attacchi saranno N volte più costosi. (Un N tipico è 5000, quindi per spezzare un singolo hash sarebbero necessari circa 2 milioni di dollari in elettricità, il problema con N super grandi è che le sue risorse computazionali sui server sono maggiori per verificare i tentativi di password).

¹ - Questo non è il modo più efficace per decifrare le password. Le liste di dizionari di milioni di password precedentemente utilizzate sono molto più efficaci, poiché molte password sono piuttosto deboli. Non raccomando le persone che generano le password stesse (in genere molto bassa entropia) o il riutilizzo delle password. Utilizzare un servizio come keepassx che consente di creare password casuali per ogni sito e archiviare in un file crittografato. Il rafforzamento della chiave + il sale unico significa che è impossibile tentare di infrangere tutti gli hash più semplici.

Le tabelle Rainbow sono tabelle hash precalcolate che vengono utilizzate per decifrare le password in un tempo relativamente più veloce perché la ricerca di una tabella è molto più veloce del calcolo di un hash.

if one can find the hashed passwords one should be able to find the corresponding salts

Il sale noto all'attaccante non creerà un grosso problema se l'autore dell'attacco tenta di crackare una password singola . Salt ti renderà difficile e dispendioso in termini di tempo per rompere un elenco di password perché per ogni password il sale è diverso.

But where does one store the salt? A salt is simply to make rainbow tables "useless", right?

Salt è memorizzato solo nel DB e per ogni password hai un diverso salt casuale. Sì, il sale rende molto difficile l'uso di una tabella arcobaleno. Le tabelle arcobaleno vengono generalmente create utilizzando password comuni utilizzate. L'aggiunta di un sale casuale rende molto difficile essere scoperti da un tavolo arcobaleno.

Couldn't an attacker just build a rainbow table, then convert all the hashes and remove the salt?

Potresti voler dire costruire un tavolo arcobaleno con sali conosciuti (prima di eseguire l'attacco reale) perché non puoi semplicemente rimuovere un sale dall'hash. Non è consigliabile ricalcolare la tabella perché se si tiene conto di tutti i sali noti, anche la dimensione della tabella sarà big.Remember trade / time trade off. Se crei le tabelle per un solo sale alla volta, stai sprecando troppa energia. L'intero scopo di creare una tabella arcobaleno è quello di decifrare un elenco di password e non una singola password.

Un'altra aggiunta di valore molto importante fornita da salting è non ci saranno due utenti che finiranno con un hash della password identico perché i sali saranno diversi. Immagina che un utente malintenzionato sia in grado di decifrare una delle password e se i sali non vengono utilizzati, l'aggressore deve semplicemente eseguire una ricerca per scoprire quali altri utenti utilizzano la stessa password.

In primo luogo, perché stai implementando un codice crittografico di basso livello per una pagina web? Si potrebbe pensare che questo è un problema risolto: si utilizza un framework che utilizza le librerie.

In secondo luogo, l'hash protegge le password in caso di perdita degli hash. Il tuo sito non fornisce l'accesso al database delle password, quindi questa situazione dovrebbe idealmente non presentarsi. I sali aiutano a difendere il database delle password nel suo complesso in quell'evento.

Se l'attaccante si concentra su una singola password da quel database, quindi non fa molta differenza. Rende solo più difficile il lavoro nel senso che l'attaccante non può semplicemente recuperare la password da una tabella arcobaleno osservando l'hash. La forzatura bruta di una password con un salt viene rallentata solo leggermente perché alcuni hash sono più hash, il che costa un paio di cicli in più nei round di hashing.

C'erano una volta i sistemi Unix che forniscono l'accesso pubblico (come i sistemi di campus per gli studenti) a cui le loro password sono state spezzate a destra ea sinistra. C'erano vari motivi per cui questo era facile, ma il problema principale era semplice: le informazioni sensibili sull'hash della password erano conservate nello stesso file degli altri campi di informazione su un utente, e quel file, /etc/passwd era leggibile a livello mondiale. La correzione consiste nel mettere le informazioni sensibili in un file separato, /etc/shadow . Presto: che termina la violazione della password da parte degli script kiddies che hanno account legittimi e non privilegiati sul sistema.

Allo stesso modo, nessuno sarà forzato a forzare le password a meno che non le lasci sfuggire. Se fuoriescono e qualcuno cerca la password di un particolare utente, c'è poco che può essere fatto per fermarli.

Utenti che utilizzano le stesse password su sistemi diversi e non cambiano per anni e gli anni saranno sempre vulnerabili. Puoi salarlo, peparlo e aggiungere ketchup; non farà la differenza.

I sali scoraggiano qualcuno che vuole rompere il database delle password nel suo insieme e raccogliere quante più password possibili. Sali significa che ogni password deve essere forzata alla bruta individualmente anziché essere semplicemente recuperata da tabelle pre-calcolate. Se un sale ha N bit, quindi, almeno idealmente, il database della tabella arcobaleno dell'attaccante deve essere 2 ^ N volte più grande. Un sale a 32 bit significa che hai bisogno di un database di tabelle arcobaleno quattro miliardi di volte più grande per cercare solo le password.

Se il tuo sito ha solo 20 utenti, ovviamente ci sono solo fino a 20 diversi sali. Quindi, ciò che un utente malintenzionato farà è prendere il dizionario delle password e cancellare ogni voce in 20 modi diversi con quei sali.

Quindi i sali non proteggono il database solo dalla ricerca della tabella arcobaleno, ma lo proteggono anche dal cracking della forza bruta di circa un fattore di N, dove N è il numero di utenti. Per le password N brute force, l'hacker deve fare N volte il lavoro come forzante bruto. (Supponendo che il sale sia abbastanza largo: almeno grande quanto il logaritmo di base 2 di N. Se un sale è solo, diciamo, largo 12 bit, allora ci possono essere solo 4096 diversi sali, indipendentemente da quanti utenti ci siano.)

Senza sali, questo non è vero. Forzare brutalmente un numero qualsiasi di password allo stesso tempo è semplice quanto forzare il bruto, quindi più utenti ci sono, più grande è il profitto per sforzo.

Ci sono un paio di fattori coinvolti nella salatura e ti manca (almeno) uno di quelli.

• Rendono inutili le tavole arcobaleno. Se qualcuno guarda nel tuo database delle password e vede che una password è "5f4dcc3b5aa765d61d8327deb882cf99", non hanno nemmeno bisogno di costruire una "tabella arcobaleno", possono solo google per quel valore e google dirà loro che è l'hash md5 di " parola d'ordine". Se le password vengono sottoposte a hash prima di essere inserite nel tuo db, il meccanismo di ricerca "rainbow table" sarà inutile. Non è necessario conservare il sale nel db per rendere inutili le tavole arcobaleno. Il tuo sale può essere sempre "xxxx" o qualsiasi altra stringa arbitraria. Se cerchi google per 6a316e1fdac8a61d9c7a2ed1cba4a804 (l'hash md5 di "xxxxpassword"), non ottieni risultati.

• Se fatto correttamente, il sale generalmente significa che un intruso ha bisogno di entrambi il tuo database e il tuo codice per violare le tue password. È possibile avere hash come password "xxxx" + password o pw.substring (0,2) + "xxxx" + pw.substring (2). L'utente malintenzionato non sa come hai salato la tua password a meno che non abbia rubato anche il tuo codice. Il tuo server web spesso non viene eseguito nella stessa casella del tuo database e, con i linguaggi di programmazione compilati, il tuo codice potrebbe non essere nemmeno disponibile sul tuo server web. Indipendentemente da ciò che sali memorizzi nel tuo db, ti consiglio anche di avere un lungo, arbitrario, salato fisso memorizzato al di fuori del db che è inoltre concatenato alla password prima dell'hashing.

• I sali unici rendono il cracking più costoso. Come ha sottolineato qualcun altro, se hai hash ogni parola del dizionario con un salt statico ("xxxx"), puoi scandire l'intero database delle password per "6a316e1fdac8a61d9c7a2ed1cba4a804" cercando chiunque sia la password sia "password". Se ogni riga utilizza un sale diverso, devi eseguire N hash solo per scoprire se uno degli utenti N ha la password "password".

• Nel secondo punto, fai attenzione solo a usare un singolo semplice sale fisso senza altri. Un cracker potrebbe provare a eseguire l'hashing di stringhe arbitrarie + "password" fino a trovare qualcuno con password "password", e quindi avrebbe sostanzialmente violato il tuo sale. In qualsiasi grande database di password ci deve essere almeno un utente la cui password è una password banale come "password".

Vedo che una tabella arcobaleno funziona ancora qui, anche se con un po 'di lavoro in più.

se x è il valore hash per password + salt e poiché salt può essere noto a tutti poiché è archiviato nel database nei file dell'applicazione, quindi posso ancora usare una tabella arcobaleno

scegli la tua tabella arcobaleno, aggiungi nuove colonne i.e hashed_password_Salt per tutti i valori hash e poi esegui un aggiornamento per la colonna con il risultato per x = hash (password + sale) poiché la colonna delle stringhe delle password comuni hai già

avrai quindi la tua tabella arcobaleno aggiornata per gestire il cracking della password usando l'attacco dizionario

Sombody può correggermi se questo non è un modo praticabile