Sale, password e sicurezza

Question

Ho letto molte delle domande su SO di questo, ma molte risposte si contraddicono o non capisco.

Si dovrebbe sempre memorizzare una password come hash, mai come testo normale. Ma dovresti memorizzare il salt (univoco per ogni utente) accanto alla password hash + sale nel database. Questo non mi sembra molto intelligente in quanto nessuno potrebbe accedere al database, cercare l'account chiamato Admin o qualsiasi altra cosa e poi elaborare la password da questo?

Answer 1

Un sacco di persone dicono "per fermare le tabelle arcobaleno" senza spiegare cosa fanno le tabelle arcobaleno o perché questo li ferma.

Le tabelle arcobaleno rappresentano un modo intelligente di precalcificare un numero elevato di hash e di archiviarle in una quantità di memoria inferiore rispetto a quella richiesta in modo ingenuo, e possono essere utilizzate per invertire rapidamente un hash. Le tabelle per le funzioni nude come hash = md5(password) e hash = sha1(password) sono comuni.

Tuttavia, possono essere generati per QUALSIASI funzione di hash che può essere descritta come output = f(input). Se si utilizza un salt del sito per tutte le password utente, ad esempio hash = md5(salt+password), è possibile creare una funzione f, f(password) = md5(salt+password). Pertanto è possibile generare tabelle arcobaleno per questa funzione, operazione che richiederebbe molto tempo, ma consentirebbe di suddividere rapidamente ogni singola password nel database.

Se il valore di sale è diverso per ciascuna password, non è possibile generare una tabella arcobaleno che crei la violazione di tutte le password nel database. Potresti generarne uno nuovo per ogni utente, ma sarebbe inutile: una forzatura bruta ingenua non sarebbe più lenta. Quindi avere un sale separato per ogni utente arresta l'attacco delle tabelle arcobaleno.

Ci sono diversi modi per farlo.modi popolari includono:

• Un sale separato per ogni utente, conservato al fianco dei loro altri dettagli nel database: hash = hashfunction(salt + password)
• Un sale globale e un valore unico per ogni utente: hash = hashfunction(salt + password + user_id) ad esempio
• Un sale globale e una per utente sale: hash = hashfunction(global_salt + user_salt + password)

Avere un sale globale potrebbe aggiungere un po 'di complessità in più per fessurazione le password, in quanto potrebbe essere conservato al di fuori del database (nel codice, per esempio), che gli attaccanti non possono guadagnare accesso a nel caso di una violazione del database. Crittograficamente non penso che aggiunga molto, ma in pratica potrebbe rallentarli.

Infine, per rispondere alla tua domanda effettiva:

Conservazione del sale a fianco dei dati utente non indebolisce l'hash. Le funzioni di hash sono a senso unico: dato l'hash di una password, anche se non salda, è molto difficile trovare quella password. La motivazione alla base della salatura non è quella di rendere più sicuro un singolo hash, ma di rendere più sicura la raccolta di più hash. Ci sono diversi vettori di attacco per una collezione di hash non salati:

• tabelle arcobaleno
• hashing delle password comuni (123, password, god) e vedere se esistono nel database e quindi compromettono tali conti
• Cerca hash identici nel database, che significa password identiche (probabilmente)

Answer 2

Il sale è destinato a disturbare le tabelle di arcobaleno esistenti. Non è una minaccia per la sicurezza sapere il sale. Se conosci il sale, dovresti comunque conoscere la password.

Answer 3

Prima di tutto, lo scopo principale di Salt è disabilitare la forzatura bruta delle password, ad esempio impedisce l'utilizzo di tabelle arcobaleno per la rapida compromissione di una password.

Anche se un utente malintenzionato accede a un database, non è così facile elaborare le password reali dai sali (soprattutto se non si dispone del codice e non si conosce il modo in cui la password è hash). Tuttavia, ciò che mi piace fare per maggiore sicurezza è anche l'hash di una password con un hash statico specificato nel codice. In questo modo non è sufficiente compromettere il database. Un esempio di tale metodo (in PHP):

$hashed_password = sha1($user_password . $user_salt . $static_salt); 

$user_salt è il sale nel database unico per ogni utente, $static_salt è il sale specificato nelle impostazioni del codice da qualche parte.

Answer 4

Se non si memorizza il sale, come si controlla se è stata fornita la password corretta?

Answer 5

Salt viene utilizzato per aumentare il tempo che un utente malintenzionato dovrebbe impiegare per trovare una password corrispondente all'hash memorizzato nel database. In genere, viene utilizzata una tabella di ricerca come la tabella arcobaleno (vedere http://en.wikipedia.org/wiki/Rainbow_table) per ottenere ciò.

Ciò che costa non è la ricerca stessa, ma il tempo per calcolare la tabella arcobaleno. L'aggiunta di un sale obbliga l'attaccante a ricalcolare una nuova tabella arcobaleno, anche se è nota all'attaccante che comprometterebbe il database

Answer 6

Bene bene, così tante discussioni ... così tante informazioni. così tante domande ... vedo che dopo tutte le domande sono le risposte ecco il riassunto.

1. Perché sale?
2. Perché Salt viene archiviato insieme all'hash di (password + sale).

Ecco la mia comprensione.

1. Gli hacker hanno una tabella arcobaleno per tutte le parole del dizionario che ha fatto con grande sforzo. Ogni tavolo da arcobaleno si fa fuori dall'hacker. In parole semplici è molto difficile.
2. Come per il punto 1, se facciamo l'hacker calcolare la tabella arcobaleno per ogni utente, allora diventerà vecchio quando conosce la password. E se l'utente cambia spesso la password, anche i nipotini degli hacker invecchieranno quando conoscono la password.
3. Ok. Quindi usa sale diverso per ogni utente. Questo fa sì che l'hacker usi un attacco separato per conoscere la password di ogni singolo utente.
4. vedo che diversi lettori hanno sottolineato, che invece di sbattere la testa su ogni singolo utente un grande hacker mettere tutti i suoi sforzi verso account di amministratore e poi si è fatto :). Quindi, in questo caso, faremo un passo avanti e quindi useremo un metodo diverso per calcolare l'hash. Diciamo che il sale non è esattamente ciò che è immagazzinato. Potrebbe essere la metà del vero e proprio hash. L'altra metà è memorizzato altrove in altro modo (calcolato in altro modo). Questa è solo una misura di sicurezza extra. E sappiamo thwt in tempi attuali, la potenza di calcolo dei computer è in aumento.Le persone etiche sanno che il super-computer più veloce del mondo impiegherà 1 anno per craccare la password dell'amministratore (solo un esempio). Quindi impongono una politica che dice cambiare la password dell'amministratore ogni 3 mesi. quando l'hacker conosce la vecchia password, la nuova è in vigore. O dire che il database è compromesso, allora i bravi ragazzi lo sapranno quando l'hacker incrina la password. E i buoni Chang le cose da allora (ricordate l'aggiornamento di alogorithms ..sha1 SHA2 e ora sha3) .....

Ok..though non del tutto completa, ma il mio punto è male ragazzi prendono sacco di tempo .... ma i bravi ragazzi sono un passo avanti per assicurarsi che conoscano la tecnologia che i malintenzionati useranno per crackare. Quindi, basta inventare una tecnologia migliore in base al tempo.

Prenditi cura ....