Memorizzare l'hash delle password degli utenti, ad es. in un database, non è sicuro poiché le password umane sono vulnerabili agli attacchi del dizionario. Tutti suggeriscono che questo è mitigato tramite l'uso di sali, ma il sale è considerato non sensibile e non ha bisogno di essere protetto.
Nel caso in cui l'attaccante ha il sale come è diventato più difficile il suo attacco di dizionario rispetto a prima? Non ha accesso al sale, efficacemente, rimuove la sua utilità?
Salt non ti protegge da un attaccante solitario che è solo dopo una password. Un utente malintenzionato che desidera solo rompere una password calcolerà hash(salt + guess) anziché hash(guess) (se lo schema password è hash(salt+password) ).
Salt aiuta se l'hacker vuole rompere molte password. Questo di solito è il caso. A volte l'aggressore sta attaccando un sito e vuole entrare in un account su quel sito, qualsiasi account. Senza sale, la maggior parte del lavoro dell'attaccante può essere utilizzato per tutti gli account, quindi può testare ciascuno dei suoi tentativi contro tutti gli account contemporaneamente. Con un sale scelto correttamente (cioè se non ci sono due account avere lo stesso sale), l'utente malintenzionato deve ricominciare da capo per ogni password con hash.
Inoltre, in un certo senso, tutti i tentativi di cracking della password stanno tentando di decifrare tutte le password degli account contemporaneamente. Questo perché gli hash possono essere precalcolati; basta che qualcuno generi una tabella di hash - o più efficientemente, un tabella arcobaleno - e il lavoro iniziale può essere distribuito a più aggressori che possono utilizzarlo su qualsiasi database di account che utilizza lo stesso algoritmo di hashing della password. Di nuovo, il sale rende queste precomputazioni inutili.
Un attacco con password a forza bruta può essere riassunto in questo modo:
hash(guess[i]) = hashed_password[j] . In un approccio ingenuo, il secondo passaggio richiede calcoli hash n × p per tentare tutte le ipotesi su tutti gli account. Tuttavia, se il primo passo ha già calcolato tutti gli hash possibili, il secondo passaggio non richiede affatto il calcolo dell'hash, basta testare se ogni hashed_password è nel database precalcato, quindi l'attacco richiede solo n ricerche di tabelle (questo può anche essere velocizzato, ma siamo già passati da n x p calcoli lenti¹ fino alle n ricerche di tabelle).
Se ogni password ha un valore diverso, per poter essere utile, la precomputazione dovrebbe includere una voce per ogni valore di sale possibile. Se il sale è abbastanza grande, la precomputazione non è fattibile. Se la precomputazione non tiene conto del sale, non sarà utile accelerare il secondo passo, perché qualsiasi funzione di hash crittografica "mescola" il suo input: conoscere l'hash di UIOQWHHXpassword non aiuta a calcolare l'hash di NUIASZNApassword . Anche per attaccare un singolo account, l'utente malintenzionato deve eseguire calcoli hash p per provare tutte le supposizioni, già un miglioramento nella ricerca su tabella singola che sarebbe sufficiente se l'autore dell'attacco ha un dizionario precalcolato.
¹ Una password non deve essere memorizzata come hash come SHA-1, ma usando una funzione hash più lenta come bcrypt o scrypt o PBKDF2 .
Ho intenzione di spiegare ogni livello di sicurezza per la password memorizzata nel database, forse questo aiuterà a chiarire l'importanza del sale.
Livello 1 : password memorizzata in chiaro nel database.
Questa è solo pura stupidità . Ma a volte, la grande azienda ottiene il loro database compromesso e, oh sorpresa, tutte le password sono archiviate in chiaro. Che peccato!
Livello 2 : password memorizzata utilizzando un algoritmo di hashing.
Questo è un passo verso una maggiore sicurezza. Se un utente malintenzionato ottiene la password con hash, non può ancora accedere utilizzando questa credenziale al servizio. Dovrà prima "disfare" la password utilizzando un Rainbow Table o brido forzante it . Ciò significa che è necessario un po 'più di lavoro da parte dell'utente malintenzionato, ma è comunque possibile recuperare la password originale.
Livello 3 : password memorizzata utilizzando un algoritmo di hashing con un salt.
Questo inizia a essere interessante. Come abbiamo visto su Livello 2 , un utente malintenzionato che ha accesso alla password con hash può forzarlo o usare una tabella arcobaleno. L'aggiunta di una parola salt alla password originale rende la tabella di colori totalmente inutile perché non prende in considerazione il sale. È ancora possibile ottenere la stringa originale usando una tabella arcobaleno, ma significherebbe che nella tabella arcobaleno esiste la password + sale. Dato che un sale è generalmente molto lungo, lo strano avere un valore hash di una stringa (40+) è quasi impossibile. L'unica soluzione rimasta è la forza bruta.
Livello 4 : password memorizzata utilizzando un algoritmo di hash con un salt e un peper.
Questo è molto interessante (è il motivo per cui sto postando la mia risposta dato che quelli attuali sono già interessanti).
Ti consiglio di usare un algoritmo di hashing come BCrypt, SCrypt o PBKDF2 dato che non sono corretti finora, e sono molto lenti nell'hack, aumentando il tempo necessario per romperne uno e poi un database completo di password.
La differenza tra sale e pepe è la loro posizione. Il sale viene generalmente memorizzato nel database ma il pepe si trova nel codice. Questo può sembrare strano, ma l'idea originale è che un database possa essere compromesso, ma non il codice, lasciando l'attacker a sale e un elenco di password hash inutili. Inoltre, aggiunge ancora più complessità alla password hash, rendendo le tabelle arcobaleno completamente inutili (se supponiamo che fossero ancora un po 'utili con un salt!).
Nel caso in cui solo il database sia compromesso, anche la forza bruta è quindi inutile poiché l'attaccante non sta cercando un valore (la password originale) ma per due valori (la password originale AND il pepe).
Se i tuoi hash non sono saldi posso generare un intero degno di hash e archiviarli in un database (tipo speciale chiamato rainbow table, è più efficiente per un gran numero di hash), quindi tutto quello che devo fare è guardarli su. Fondamentalmente una memoria gigante rispetto all'ottimizzazione del tempo di CPU. Inoltre, se vedo due utenti con lo stesso hash, so che stanno usando la stessa password.
Un sale rende unico l'hash della password di ogni utente e, se lo fai correttamente, sarà probabilmente unico anche se usa la stessa password su un altro sito (non insolito), e quindi dovrei effettivamente prendere parola, applica sale e cancellalo, ripeti per la prossima voce nel dizionario.
Gli hash non salati sono vulnerabili agli attacchi di ricerca. Esistono database liberamente disponibili contenenti milioni di hash delle password (principalmente MD5 e SHA1) che possono essere utilizzati per cercare il testo in chiaro di un hash. Questi possono essere basati su database relazionali standard o su formati di database specializzati come le tabelle arcobaleno.
Quindi, ecco un esempio:
7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53 (non salato)
2d67062d67b4d0eaca31a768e901d04982de7352 (salato con prefisso "RxB6aE")
Una rapida ricerca sul primo hash rivelerà che il testo in chiaro è "passw0rd". Tuttavia, quest'ultimo non è molto probabile che venga trovato. Nel caso in cui il sale non sia noto all'attaccante, rende difficili gli attacchi di dizionario e bruteforce.
Se stai cercando di proteggere le password in un database, dovresti usare qualcosa come bcrypt. Usa un gran numero di iterazioni di un algoritmo hash per rendere ogni calcolo lento. Pertanto, gli attacchi bruteforce, gli attacchi di dizionario e la costruzione di tabelle arcobaleno sono altamente irrealizzabili.