Ho fatto un po 'di lettura sull'argomento di Hash and Sali e mi è venuta un'idea per uno schema di salatura, ma volevo controllarlo con alcune persone più istruite di me.
La mia idea di base è di usare l'hash della password iniziale come sale per un secondo hash.
password = 'foobar'
final_hash = sha1( sha1( password ) + password )
Se qualcuno può spiegare perché questa potrebbe essere una cattiva idea, l'Id lo apprezza davvero.
Grazie!
Non otterrai nulla. Considerare due utenti con la stessa password, salt, tra gli altri, è progettato per ottenere diversi hash per la stessa password.
Nell'esempio:
Ma con il tuo algoritmo finirai con lo stesso hash:
Inoltre, non rollare il tuo proprio .
Un sale è usato per:
Un sale dovrebbe essere casuale e sufficientemente lungo (ad esempio 128 bit casuali) in modo che la sua entropia diventi grande perché solo un sale con una grande entropia può evitare gli attacchi attraverso i tavoli arcobaleno.
Di solito, non c'è motivo di ricavare il sale da alcuni degli attributi dell'utente, ad es. la password o il nome utente. Uno schema per l'hashing della password che è comunemente usato in pratica è bcrypt. L'implementazione Java di bcrypt I'm aware ( vedere ) crea automaticamente un salt casuale per ogni password. Il sale fa parte dell'hash di bcrypt in modo da non dover gestire il sale in alcun modo speciale. L'implementazione fornisce anche metodi per controllare le password che decompongono automaticamente l'hash di bcrypt nel suo salt e l'hash della password effettiva.
Bcrypt offre anche un fattore di carico per aumentare la complessità richiesta per calcolare un hash. Questo è utile per evitare attacchi di forza bruta perché ostacola un attaccante a calcolare un gran numero di hash.
Complessivamente non vi è alcun motivo per implementare il proprio schema per l'hashing delle password.
Leggi Come fare in modo sicuro le password di hash? - non dovresti eseguire il rollover. @ThomasPornin ha una ottima risposta a questa domanda , e la sezione sulla generazione del sale include (tra molto più buoni consigli ) la seguente saggezza:
The main and only point of the salt is to be as unique as possible. Whenever a salt value is reused anywhere, this has the potential to help the attacker.
For instance, if you use the user name as salt, then an attacker (or several colluding attackers) could find it worthwhile to build rainbow tables which attack the password hashing function when the salt is "admin" (or "root" or "joe") because there will be several, possibly many sites around the world which will have a user named "admin". Similarly, when a user changes his password, he usually keeps his name, leading to salt reuse. snip
The cheap way to obtain uniqueness is to use randomness. If you generate your salt as a sequence of random bytes from the cryptographically secure PRNG that your operating system offers (/dev/urandom, CryptGenRandom()...) then you will get salt values which will be "unique with a sufficiently high probability". 16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough. snip
In sostanza, non è possibile utilizzare la password per generare un salt per la password, dal momento che l'input SOLO è la password!
Dovresti utilizzare un generatore di numeri casuali per generare sali univoci per utente (e memorizzarli in testo in chiaro nel database, insieme all'hash della password e al numero di iterazioni o al fattore di lavoro utilizzato [così puoi facilmente aumentarlo in seguito] ), e il consiglio generale qui è approssimativamente un salt casuale di 16 byte. 8 byte è probabilmente un minimo pratico per la lunghezza del sale.
Leggi altre domande sui tag password-policy hash salt