2012-10-04 17 views
24

Eventuali duplicati:
Secure hash and salt for PHP passwordsSale e password

Per la mia password dovrei usare il sale come questo (il sale sarà unico per ogni utente e non memorizzati direttamente con la password) ...

$salt = sha1(md5("coders gonna code")); 
$password = md5($salt.$password); 

o sarebbe bene se ho appena usato:

$password = md5($password); 

perché se ho usato il sale, anche se l'utente compone una password errata, come la password non sarà importa, perché il sale (in questo caso) sarebbe 145ac26ff093c6e1317f7d5fb4c9fd11c77be975 così la voce per la password non ci sarebbe 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password che secondo a http://howsecureismypassword.net/ ci vorrebbero 3 anni e ottodecillione per rompere .... quindi opinioni? O dovrei essere anche peggio e andare

$password = md5($salt.$password.md5($salt)); 

Se la persona è andato abbastanza lontano per ottenere l'hash del sale, sarebbe nulla in grado di fermare poi andare futher? < più di una dichiarazione questa ultima password


Per tutti coloro che hanno detto che dovrei farlo per utente ... Lo so, questo è solo un esempio.

+0

Mi dispiace dimenticato di modificare -.- – FabianCook

+4

È possibile utilizzare 'PBKDF2' invece di _salting_ le password. – Florent

+0

Leggi questo http://www.codinghorror.com/blog/2012/04/speed-hashing.html – jurgemaister

risposta

13

È necessario modificare il sale in modo che sia specifico per ogni utente, non una costante di sistema. Ciò renderà molto più sconvenienti gli attacchi dei tavoli arcobaleno contro gli hash delle password.

C'è una buona annotazione sull'evoluzione della salatura in questo article di Troy Hunt.

Modifica

$salt qualcosa di unico per ogni record password, che aggiunge molto entropia ad esso. Di solito si tratta di una sequenza casuale di byte, memorizzata con l'account utente.

L'hash è tradizionalmente fatto sulla concatenazione di salt + password.

$passwordHash = hash($salt.$password); 

Come altri hanno già detto, non utilizzare MD5 per l'hashing. È rotto.

L'applicazione di ulteriori algoritmi proprietari a password o salt prima dell'hashing è not recommended. Invece, guarda una soluzione di settore come PBKDF2, che, oltre alla salatura, richiede anche molte iterazioni (tipicamente> 10k) che rallentano ulteriormente l'aggressore.

Se si adotta OWASP guidelines, il numero di hash eseguiti deve essere aumentato regolarmente (per contrastare la legge di Moore). Il numero di hash deve essere mantenuto anche per utente, il che significa che è necessario memorizzare la tripla di password hash, salt e numero di iterazioni.

+0

Controlla modifica. Grazie, ma lo so. :) – FabianCook

+2

Penso che questo risponda alla domanda il meglio, perché a me sembra che l'OP non sappia chiaramente perché dovrebbe usare Salt con le sue password. Se usi sale fisso, non importa se ci vorranno 3 miliardi di anni, per craccare la password con la forza bruta, perché l'attaccante guarderà solo la tua tabella di database, vedi che ci sono 3000 password con lo stesso valore di hash e supponiamo che sia "password" o "12345" o qualsiasi altra cosa. Si utilizzano gli hash dinamici in modo che la password hash e slated non possa essere indovinata con mezzi statistici. –

13

Si sta utilizzando il sale in modo errato. I sali dovrebbero essere imprevedibili; il tuo sale è l'esatto opposto di quello (fisso). Dato che un hash fisso non ha assolutamente alcun beneficio, sembra anche che tu stia contando sul fatto che il sale non sia noto all'attaccante. Questa è la definizione di sicurezza attraverso l'oscurità, che è un'altra cattiva pratica.

Che cosa si dovrebbe fare è:

  1. Utilizzare una stringa imprevedibile di ragionevole durata, come il sale. Le stringhe di 8 caratteri generate casualmente da un pool come lettere minuscole/maiuscole e cifre vanno bene.
  2. Utilizzare un sale diverso per ogni utente e modificarlo ogni volta che cambiano la password.
  3. Sposta da MD5 (che è considerato interrotto) a un'altra funzione di hash più adatta a questa applicazione. SHA-1 è migliore perché non è considerato rotto; bcrypt è il migliore perché ha un fattore di carico configurabile.
+0

Controlla modifica. Grazie, ma lo so.:) – FabianCook

+0

@SmartLemon: modifica o rimuovi le prime righe della tua domanda in modo appropriato. Una piccola modifica non è sufficiente per farci sapere esattamente cosa stai facendo. – Jon

+0

Ti piace? Penso che sia ok ora – FabianCook

9
  1. Non utilizzare MD5 come algoritmo di hash, utilizzare qualcosa di più sicuro, come SHA256 o addirittura bcrypt.

  2. Sicuramente la password, se qualcuno ha ottenuto l'accesso al database, non sarebbe in grado di invertire le password per gli hash comuni o utilizzando tecniche come gli attacchi arcobaleno.

http://michaelwright.me/php-password-storage

http://en.wikipedia.org/wiki/Bcrypt

+2

Tutti pensano che sia corretto? Penso che sia così? – FabianCook

+1

Sha256 non è molto sicuro ancora tbh, qui c'è anche una versione funzionante di bcrypt fatta bene con una gamma di byte salt http://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing- passwords-in-php – Sammaye

0

Sali sono destinate ad essere completamente casuale, e non collegati alla password attuale si memorizza un hash di.

Che cosa si dovrebbe davvero fare è generare un sale del tutto casuale, quindi fare

$password = md5($salt.$password); 

e memorizzare il nome utente, il sale dell'utente e hashing la password.

+1

Non suggerire MD5, non è sicuro. –

+0

Verifica modifica. Grazie, ma lo so. :) – FabianCook

+0

@ H2CO3 perché MD5 non è sicuro? –

2

Penso che il sale sia inteso qui in modo errato. L'idea del sale è che dovrebbe essere unico per hash. Il motivo è che quando crei hash alcune stringhe diverse potrebbero avere lo stesso hash.

Nel tuo esempio il gioco è hashing una password troppo in modo che non sarà simile: 145ac26ff093c6e1317f7d5fb4c9fd11c77be975password

P.S. Usa bcrypt. È molto più affidabile

3

Prima di tutto non si dovrebbe mai memorizzare direttamente md5, che si è già riconosciuto. PHP 5.5 porterà nuovi metodi per creare e verificare facilmente le password in 1 riga, fino a quel momento è possibile utilizzare https://github.com/ircmaxell/password_compat (compatibile con le versioni precedenti) per generare & verificare gli hash delle password sicure.

Problemi correlati