Salatura password 101

Question

Qualcuno potrebbe aiutarmi a capire come funziona la salatura?

Finora ho capito quanto segue: Password

1. Convalida
2. generare una stringa casuale
3. Hash la password e la stringa casuale e concat, poi memorizzarli nel campo della password ...

Come immagazzinare il sale o sapere cosa è quando un utente effettua l'accesso? Lo immagazziniamo nel suo campo? Se non lo facciamo, come fa l'applicazione a capire cos'è il sale? E se lo immagazziniamo, non sconfigge l'intero scopo?

Answer 1

Il sale è combinato con la password prima dell'hashing. i valori password e salt clear sono concatenati e la stringa risultante è hash. questo garantisce che anche se due persone avessero la stessa password, si otterrebbero diversi hash risultanti. (rende anche gli attacchi noti come attacchi di dizionario che utilizzano tabelle arcobaleno molto più difficili).

Il sale viene quindi memorizzato in formato originale/chiaro insieme al risultato dell'hash. Successivamente, quando si desidera verificare la password, si eseguirà nuovamente il processo originale. Combina il sale del record con la password fornita dall'utente, elimina il risultato, confronta l'hash.

Probabilmente lo sapete già. ma è importante ricordare. il sale deve essere generato casualmente ogni volta. Deve essere diverso per ogni hash protetto. Spesso il RNG viene utilizzato per generare il sale.

esempio So..for:
user-password: "mypassword"
sale casuale: "abcdefg12345"
risultante-in chiaro: "mypassword: abcdefg12345" (come li combinano dipende da voi più a lungo. ogni volta che usi lo stesso formato di combinazione).
hash il testo chiaro risultante: "somestandardlengthhashbasedonalgorithm"

Nel database ora è necessario memorizzare l'hash e il sale utilizzato.L'ho visto in due modi:

Metodo 1:
field1 - sale = "abcdefg12345"
field2 - password_hash = "somestandardlengthhashbasedonalgorithm"

Metodo 2:
field1 - password_hash = "abcdefg12345: somestandardlengthhashbasedonalgorithm "

In entrambi i casi è necessario caricare il sale e la password hash fuori del vostro database e rifare l'hash per il confronto

Answer 2

salt <- random 
hash <- hash(password + salt) 
store hash:salt 

tardi

input password 
look up hash:salt 
hash(password+salt) 
compare with stored hash 

capito?

Answer 3

Questa è una buona descrizione di come memorizzare le password - che cosa sono i sali, quali la crittografia da usare, ecc

http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html

Answer 4

Se stai usando un algoritmo di hashing noto, qualcuno potrebbe avere un elenco di molte password possibili già con hash usando quell'algoritmo e confrontare gli elementi da quella lista con una password con hash che vogliono crackare (attacco dizionario).
Se si "saltano" tutte le password prima di eseguirne l'hashing, questi dizionari sono inutili, perché dovrebbero essere creati utilizzando il proprio sale.

Answer 5

Come conserviamo il sale, o sappiamo cosa è quando un utente effettua il login? Lo immagazziniamo nel suo campo?

Sì.

E se lo immagazziniamo, non sconfigge l'intero scopo?

No. Lo scopo di un sale non è essere un segreto, ma semplicemente per evitare che un utente malintenzionato di ammortizzare il costo di calcolo tabelle arcobaleno oltre tutti i siti in tutto il mondo (non sale) o tutti gli utenti nel vostro sito (singolo sale usato per tutti gli utenti).

Answer 6

Secondo Crittografia pratica (Neils Ferguson e Bruce Schneier), è necessario utilizzare gli hash salati e stirati per la massima sicurezza.

x[0] := 0 
x[i] := h(x[i-1] || p || s) for i = 1, ..., r 
K := x[r] 

where 
    h is the hash (SHA-1, SHA-256, etc.) 
    K is the generated hashed password 
    p is the plaintext password 
    r is the number of rounds 
    s is the randomly generated salt 
    || is the concatenation operator 

Il valore salt è un numero casuale memorizzato con la password crittografata. Non ha bisogno di rimanere segreto.

Lo stretching è l'atto di eseguire l'hash più volte per renderlo computazionalmente più difficile per un utente malintenzionato per verificare molte permutazioni delle password. r deve essere scelto in modo che il calcolo richieda circa 200-1000 ms sul computer dell'utente. r potrebbe dover essere aumentato man mano che i computer diventano più veloci.