2009-07-29 13 views
12

Ho un database di password con hash che non aveva aggiunto sale prima che fossero hash. Voglio aggiungere sale a nuove password. Ovviamente non posso rifare quelli esistenti.Come aggiungeresti il ​​sale agli hash delle password esistenti?

Come migrare in un nuovo sistema di hashing?

+0

Sei in realtà password di hashing o qualcosa di più complesso? A causa di un errore di codifica, mi trovo su una barca simile, ma il codice originale blocca in modo efficace "1" + loginname + "" + password - che è abbastanza complesso da rendere le tabelle arcobaleno piuttosto non fattibili (specialmente dal momento che il login non è utente- selezionato). –

+0

Stavo tagliando la password verso l'alto. Sembra che tu abbia già aggiunto il sale. La tua strada sembra buona perché oltre al sale, le password uguali non avranno lo stesso hash perché stai aggiungendo il nome di accesso. –

risposta

31

Certo che puoi. Basta aggiungere un sale all'hash esistente e cancellarlo di nuovo. Ovviamente ciò richiederà che tutti gli accessi futuri passino attraverso lo stesso processo, il che significa che devono essere richiamate due funzioni hash, ma molti schemi legittimi lo fanno comunque in modo che non abbia un cattivo odore come si potrebbe pensare.

Salare una password è uno sforzo per difendersi dai tavoli arcobaleno. In questo caso il sale non ha bisogno di essere un segreto.

http://en.wikipedia.org/wiki/Rainbow_tables#Defense_against_rainbow_tables

Si può effettivamente vedere in questo articolo

hash = MD5 (MD5 (password) . salt) 

Che è lo stesso metodo esatto si sarebbe utilizzando. (Tranne una funzione di hashing diversa.)

+0

+1 - Mi piace di più di quello che stavo pensando –

+0

Idea interessante. Sei sicuro che in qualche modo non ostacoli la sicurezza? Soprattutto in questo modo, una persona che ottiene le stringhe dopo il secondo hash avrà molte informazioni sul passo precedente (come la lunghezza costante, ad esempio), che potrebbe consentirgli di aiutarlo a trovare il sale. –

+3

I sali non sono segreti. In realtà è necessario salvarli (in testo normale) insieme a ciascun utente. –

2

Si potrebbe aggiungere una colonna, costituita da un flag che indica se l'utente ha un vecchia (senza sale) o di un hash nuova (con il sale).

Una buona idea è, a quel punto, forzare tutti gli utenti a cambiare le loro password all'accesso. In questo modo è possibile sbarazzarsi di quella colonna alla fine.

+0

o avere la colonna come hash_type (nosalt, md5, sha1, sha512). Se è "nosalt", fai una cosa, se le sue altre, c'è una colonna di sale usata e memorizzata altrove nella riga da usare nel confronto - con la funzione di hash appropriata quando arrivi ad aggiornarla (dato che MD5 sembra già più debole). –

14

Come soluzione rapida, è possibile creare una colonna salata nel database e, quando un utente accede correttamente all'hash precedente, è possibile utilizzare la password immessa con un salt e creare un nuovo hash.

+0

ooo, sembra una buona idea –

+0

Questo sarebbe il mio approccio pure. Il refactoring estende definitivamente il codice passato e può - in realtà, * deve * - essere eseguito a livello di database. –

+0

+1, schema eccellente. – nik

0

Ci sono some ways here che potrebbero funzionare per voi.
Ricorda che qualsiasi modello costante che aggiungi all'hash esistente è inutile (uno dei trucchi su quel link suggerisce qualcosa del genere). Non ci dovrebbero essere schemi identificabili che possano essere usati per isolare il sale.

Ovviamente, il modo migliore sarebbe migrare verso una tabella hash salata.

0

Crea un nuovo campo nel tuo database denominato "salato" con un tipo di vero/falso (o qual è l'equivalente nel tuo DBMS). Imposta tutti i valori su falso per gli hash esistenti. Ogni volta che viene aggiunto un nuovo hash salato, imposta il campo "salato" su true.

Quindi, tutto ciò che dovete fare è gestire i due tipi di hash in modo diverso nel vostro codice.

Questa è più di una soluzione generale rispetto a una specifica, ma dovrebbe risolvere il problema.

0

Se si memorizza il sale all'interno dell'hash, dovrebbe essere abbastanza semplice in avanti per determinare se è incluso un sale controllando la lunghezza dell'hash. Se non c'è un salt, basta cancellare la password, se c'è un salt, hash la password + salt.

Non è necessario disporre di una colonna booleana nel database.

0

Il modo migliore per memorizzare il mio sale è che incorporo il valore di sale all'interno della password hash + salt che ho appena creato. Non appendo la stringa salata all'inizio o alla fine dell'hash, ho letteralmente inserito il sale nell'hash.

+0

Non è così che dovrebbe essere usato un sale? Per essere sicuro di non fraintendervi, intendete hash (sale + password)? – Gary

1

Mi sono occupato di un problema simile che coinvolge più tecniche di hashing. Ho usato l'approccio della codifica di un tipo di metodo hash anche nel database (cioè "alpha", "beta", "gamma", "delta"). Ho segnato tutti gli hash correnti con il livello appropriato. Come gli utenti hanno effettuato il login, ho convalidato le loro password e le ho re-hashed usando i metodi aggiornati. Le nostre password scadono dopo 90 giorni, quindi era solo una questione di attesa per 3 mesi fino a quando tutte le password che utilizzavano i vecchi metodi potevano essere ripristinate.

Problemi correlati