modo ottimale per salare la password?

5

Un buon modo per salare la password?
Ho letto alcune risposte relative alla salatura della password. Ma ho iniziato a confondermi. Mi sono imbattuto in alcune funzioni utilizzate per generare sale come:

Così tante funzioni là fuori, quindi quale devo usare?
e una mini domanda:
Quello che so è il sale deve essere il più casuale possibile per la password di ogni utente. Attualmente sto usando bit pseudo-casuali (come in terzo nella lista sopra) per generare sale su bcrypt- > hash (sale + password) e memorizzare il sale insieme alla password nella stessa riga in mysql. Sto implementando questo sbagliato?

    
posta Tian Loon 06.09.2012 - 06:36
fonte

3 risposte

7

Per essere efficace, un sale dovrebbe essere casuale (imprevedibile) e unico (quindi, un nonce). Non deve essere molto lungo (anche se ciò non fa male).

La tua implementazione è come maneggiare un sale. Tuttavia, bcrypt include già un sale, quindi i tuoi sforzi sono un po 'ridondanti. Tuttavia, non fa assolutamente male a nessuno.

    
risposta data 06.09.2012 - 08:39
fonte
6

Normalmente, se ricordo male, Bcrypt ha il suo built in salt. Quindi non è necessario definire il proprio sale in quanto Bcrypt genera i sali durante l'hashing e li memorizza con l'output.

Da stackoverflow :

Memorizzato nel database, un% hash "%" hash "potrebbe avere un aspetto simile al seguente:

$2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

  • bcrypt identifica la versione dell'algoritmo 2a che è stata utilizzata.
  • bcrypt è il fattore di costo; Vengono utilizzate 2 10 iterazioni della funzione di derivazione della chiave (il che non è abbastanza, a proposito, consiglierei un costo di 12 o più.)
  • 10 è il sale e il testo cifrato, concatenato e codificato in una Base-64 modificata. I primi 22 caratteri decodificano in un valore di 16 byte per il sale. I caratteri rimanenti sono testo cifrato da confrontare per l'autenticazione.
  • vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa sono usati come delimitatori per la sezione di intestazione dell'hash.

Questo esempio è tratto dalla documentazione per l'implementazione ruby di Coda Hale

    
risposta data 06.09.2012 - 08:35
fonte
3

Un sale deve essere unico . Non deve essere nient'altro (alcuni algoritmi di hashing della password hanno requisiti specifici sulla lunghezza del sale, ma, in generale, è di forma libera).

Unicità dovrebbe essere compreso in tutto il mondo e per tutti i secoli. Idealmente. Essere unici per il tuo server non è del tutto sufficiente (un utente malintenzionato potrebbe tentare di attaccare più server contemporaneamente, a costo di attaccarne uno). Essere unici in un dato momento non è del tutto sufficiente (ad esempio se riutilizzi il sale ogni volta che un utente cambia la sua password, un utente malintenzionato potrebbe provare ad attaccare sia la vecchia che la nuova password per il costo di una password sforzo di cracking).

Un modo semplice per ottenere il giusto tipo di unicità è casualità . Essere imprevedibilmente casuali non è necessario per un sale, ma se il sale è una sequenza di almeno 128 bit (16 byte) che sono ottenuti da un PRNG crittograficamente strong, allora si otterrà l'unicità "gratuitamente" con una schiacciante probabilità (e è abbastanza buono).

(La casualità imprevedibile è un requisito per altri oggetti che a volte vengono erroneamente chiamati "sali", come IV per la crittografia CBC, presumo che quando si dice "salt" si stia davvero parlando di password hashing.)

    
risposta data 06.09.2012 - 13:21
fonte

Leggi altre domande sui tag