it-swarm.dev

Perché usare il sale è più sicuro?

Memorizzazione dell'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 ciò è mitigato dall'uso di sali, ma il sale è considerato non sensibile e non ha bisogno di essere protetto.

Nel caso in cui l'attaccante abbia il sale, in che modo l'attacco con il dizionario è diventato più difficile di prima? Non avere accesso al sale, effettivamente, rimuove la sua utilità?

51
Jim

Salt non ti protegge da un attaccante solitario che è solo dopo una password. Un utente malintenzionato che desidera semplicemente violare una password calcolerà hash(salt + guess) anziché hash(guess) (se lo schema della password è hash(salt+password) ).

Salt aiuta se l'attaccante vuole violare molte password. Questo di solito è il caso. A volte l'attaccante 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 utilizzata per tutti gli account, in modo da poter testare ciascuno dei suoi tentativi su tutti gli account contemporaneamente. Con un salt scelto correttamente (cioè se non ci sono due account con lo stesso salt), l'attaccante deve ricominciare da capo per ogni password con hash.

Inoltre, in un certo senso, tutti i tentativi di decodifica delle password stanno tentando di decifrare tutte le password degli account contemporaneamente. Questo perché gli hash possono essere pre-calcolati; basta che qualcuno generi una tabella di hash - o più efficacemente un Rainbow table - e che il lavoro iniziale possa essere distribuito a più aggressori che possono usarlo su qualsiasi database di account che usa lo stesso algoritmo di hashing della password. Ancora una volta, il sale rende inutili questi pre-calcoli.

Un attacco con password a forza bruta può essere riassunto in questo modo:

  1. Effettua qualsiasi pre-calcolo che l'autore dell'attacco ritenga utile, ad esempio la creazione di una tabella Rainbow (che è un modo efficace per rappresentare una tabella che associa gli hash a password comuni).
  2. Per ognuno dei n account che l'attaccante è interessato a violare, e per ciascuno dei p password indovina che l'attaccante include nel suo dizionario, verifica se hash(guess[i]) = hashed_password[j].

In un approccio ingenuo, il secondo passaggio richiede n × p calcoli hash per provare tutte le ipotesi su tutti gli account. Tuttavia, se il primo passaggio ha già calcolato tutti gli hash possibili, il secondo passaggio non richiede affatto il calcolo dell'hash, verificando solo se ogni hashed_password si trova nel database precompilato, quindi l'attacco richiede solo n ricerche di tabelle (questo può anche essere accelerato, ma siamo già passati da n x p calcoli lenti¹ fino a n ricerche nella tabella).

Se ogni password ha un salt diverso, quindi per essere utile, il precomputazione dovrebbe includere una voce per ogni possibile valore salt. Se il sale è abbastanza grande, il pre-calcolo non è fattibile. Se il pre-calcolo non tiene conto del sale, non sarà utile accelerare il secondo passaggio, poiché 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'attaccante deve eseguire p calcoli hash per provare tutte le ipotesi, già un miglioramento nella ricerca della singola tabella che sarebbe sufficiente se l'attaccante ha un dizionario precompilato.

¹ Una password non deve essere memorizzata come hash come SHA-1, ma utilizzando una funzione hash più lenta come bcrypt o scrypt o PBKDF2 .

Spiegherò ogni livello di sicurezza per la password memorizzata nel database, forse questo aiuterà a chiarire l'importanza di Salt.

Livello 1 : password archiviata in chiaro nel database.

Questa è solo pura stupidità . Ma a volte, le grandi aziende vengono compromesse dal loro database e, sorpresa, tutte le password vengono archiviate in modo 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 queste credenziali per il servizio. Dovrà prima "annullare l'hash" della password usando un Rainbow Table oppure con brute forzamento esso . Ciò significa che richiede all'autore dell'attacco un po 'più di lavoro, ma può ancora essere possibile recuperare la password originale.

Livello 3 : password memorizzata usando un algoritmo di hashing con un salt.

Questo inizia ad essere interessante. Come abbiamo visto in Livello 2, un utente malintenzionato che ha accesso alla password con hash può forzare la forza o utilizzare una tabella Rainbow. L'aggiunta di un salt alla password originale rende il tavolo Rainbow totalmente inutile perché non prende in considerazione il salt. È ancora possibile ottenere la stringa originale utilizzando una tabella Rainbow, ma significherebbe che nella tabella Rainbow esiste la password + salt. Dato che un sale è generalmente molto lungo, lo strano che ha un valore hash di una stringa (40+) è quasi impossibile. L'unica soluzione rimasta è la forza bruta.

Livello 4 : password memorizzata usando un algoritmo di hashing con un sale e un peper.

Questo è molto interessante (è il motivo per cui sto postando la mia risposta poiché quelli reali sono già interessanti).

Ti consiglio di utilizzare un algoritmo di hashing come BCrypt, SCrypt o PBKDF2 poiché non sono stati finora scoperti, e sono molto lenti ad hackerare, aumentando il tempo di interromperne uno e quindi un database completo di password.

La differenza tra sale e pepe è la loro posizione. Il sale è generalmente archiviato nel database ma il pepe si trova nel codice. Questo può sembrare strano ma l'idea originale è che un database può essere compromesso, ma non il codice, lasciando all'attaccante un salt e un elenco di inutili password con hash. Inoltre, aggiunge ancora più complessità alla password con hash, rendendo le tabelle Rainbow completamente inutili (se supponiamo che siano ancora un po 'utili con un sale!) .

Nel caso in cui sia compromesso solo il database, anche la forza bruta è quindi inutile poiché l'attaccante non sta cercando un valore (la password originale) ma per due valori (la password originale E il pepe).

16
Cyril N.

Se i tuoi hash non sono salati, posso generare interi dizionari di hash e archiviarli in un database (tipo speciale chiamato tabella Rainbow, è più efficiente per un gran numero di hash), quindi tutto ciò che devo fare è cercarli. Fondamentalmente una memoria gigante contro l'ottimizzazione del tempo della CPU. Inoltre, se vedo due utenti con lo stesso hash, so che stanno usando la stessa password.

Un salt rende l'hash della password di ogni utente unico, e se lo fai nel modo giusto sarà probabilmente unico anche se usano quella stessa password su qualche altro sito (non insolito), e quindi dovrei effettivamente prendere Word, applicare salt e l'hash, ripetere per la prossima voce nel dizionario.

8
ewanm89

Gli hash non salati sono vulnerabili agli attacchi di ricerca. Esistono database liberamente disponibili contenenti milioni di hash di 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 Rainbow.

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, non è molto probabile che quest'ultimo venga trovato. Nel caso in cui il salt 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. Utilizza un gran numero di iterazioni di un algoritmo di hash per rallentare ogni calcolo. Pertanto, gli attacchi di forza bruta, gli attacchi con dizionario e la costruzione di tavoli Rainbow sono altamente fattibili.

6
Polynomial