Migrazione password db off MD5 concatenando MD5 e Bcrypt?

8

Ho un sistema legacy che attualmente memorizza password MD5 non salate. Sfortunatamente, alcuni altri controlli non sono disponibili (come la possibilità di scadere delle password) e sto cercando di aggiornare il mio algoritmo a qualcosa di più recente ed evitare di chiedere all'utente una nuova password.

Mi chiedo quale sarà l'impatto se userò qualcosa come un bcrypt sull'hash MD5 attuale. In altre parole:

  1. L'utente invia la password di testo in chiaro
  2. La password viene sottoposta a hash con MD5
  3. L'hash MD5 è hash con bcrypt
  4. Hash confrontati per scopi di autenticazione

In qualche modo questo diminuirà la forza dell'hash in bcrypt?

    
posta BurgerMeister 06.04.2016 - 19:48
fonte

2 risposte

8

In pratica, in sostanza, MD5 inserisce le password degli utenti prima di inserirle in BCrypt.

Sebbene MD5 sia un algoritmo veloce e malamente interrotto, non rimuove alcuna entropia dalle password (a meno che non abbiano più di 128 bit di entropia, ma la password dell'utente medio ne avrà molto meno). Quindi l'entropia che inserisci in BCrypt è sempre la stessa.

Quando un utente malintenzionato ruba il tuo database e vuole forzarlo, devono comunque eseguire BCrypt, invece di eseguirlo su un milione di password più comuni, lo eseguiranno sugli hash MD5 del milione più password comuni. Ciò non richiederà molto più tempo, ma non sarà neanche più breve.

Quindi, per quanto vedo, non c'è davvero niente di sbagliato nel tuo piano.

    
risposta data 06.04.2016 - 22:02
fonte
4

Per prima cosa, vedi questa domanda e la mia risposta perché penso che copra la maggior parte della tua domanda.

È bene che tu voglia aggiornare la tua password db off MD5 non salato. Dato che non hai la possibilità di far scadere le password degli utenti, devi assicurarti che nessuna password nel database sia lasciata come MD5 non salato.

In pratica hai 3 opzioni su come fare questo:

  1. Sposta tutti in Bcrypt immediatamente eseguendo uno script sul database per raddoppiare l'hash MD5 corrente e memorizzare Bcrypt(MD5($passwd)) nel database. Al loro primo accesso vedi che la loro password in chiaro ha la possibilità di spostarli a Bcrypt($passwd) , oppure puoi lasciare il doppio hashing per sempre.

  2. Lascia la password di tutti come MD5 nel database e aggiornali a Bcrypt al successivo accesso .

  3. Fai 1. o 2. accoppiato con una scadenza della password che rimuoverà il loro hash dal db e li costringerà a fare un recupero se non hanno effettuato il login dopo X volta .

Pro / Contro

  1. È generalmente accettato nella comunità della sicurezza che il "doppio hashing" sia valido: non ti darà più sicurezza, ma non indebolirà neanche la tua sicurezza. Ecco due domande su crypto.SE su questo argomento: [più matematico] e [more esplicativo] . Il vantaggio qui è che se il tuo db di hash delle password viene rubato domani, tutti i tuoi utenti sono protetti dalla tecnologia più recente, che abbiano o meno effettuato l'accesso di recente. Questo è davvero bello considerando che anche se un utente non ha effettuato l'accesso per 5 anni, potrebbe comunque usare quella password su altri siti. Un altro vantaggio è che se scegli di andare con l'opzione Bcrypt(MD5($passwd)) , allora non hai realmente bisogno di modifiche allo schema db. Vorrei fare questa opzione.

  2. Come accennato in precedenza, questa opzione non offre alcuna protezione agli utenti che non effettuano nuovamente l'accesso e richiede modifiche dello schema db per tenere traccia di chi è su MD5 e chi è su Bcrypt. Inoltre, se la tua password db viene rubata tra un paio di mesi / anni, gli hacker vedranno quali utenti sono su MD5 e creeranno le loro password per prime, quindi stai essenzialmente gettando via la sicurezza per gli utenti che non accedono mai più - e come accennato sopra questo è un problema perché gli utenti tendono a riutilizzare le password tra i siti. Nel complesso, questa opzione è più utile per una sicurezza inferiore e penso che sia irresponsabile nei confronti dei tuoi utenti .

  3. Se sei disposto a scadere le password, combinare questo con 1. ti offre opzioni di manutenzione, e in effetti rende 2. un'opzione praticabile dal momento che tutti gli hash MD5 saranno fuori dal tuo db dopo un determinato periodo di tempo. Ma dal momento che hai detto che la scadenza non è un'opzione, non mi soffermerò su questo.

Due cose aggiuntive a cui vuoi pensare sono:

  • Sia che tu voglia ritirare MD5 dal tuo codice di accesso, o se sei felice di fare Bcrypt(MD5($passwd)) per sempre. Non penso ci sia alcun motivo di sicurezza per rimuovere il passo MD5, ma se si vuole ritirare MD5 allora si dovrà fare qualcosa di complicato sul primo login di un utente, aggiungere una colonna db per tenere traccia del metodo di hashing che stanno usando, ecc.

  • Pensa a cosa farai in 5 anni quando scopriremo qualche difetto in bcrypt e tutti si trasferiranno nel nuovo SuperHash onnipotente. Se stai memorizzando Bcrypt(MD5($passwd)) , puoi eseguire lo stesso trucco e passare a SuperHash(Bcrypt(MD5($passwd))) e tutto andrà bene. Se, tuttavia, hai deciso di spostare gli utenti sul dispositivo di pulizia Bcrypt($passwd) , devi fare alcune cose più difficili con le colonne db perché c'è un buon cambiamento che avrai utenti che non hanno mai effettuato l'accesso per l'aggiornamento al nuovo hash.

risposta data 06.04.2016 - 22:12
fonte

Leggi altre domande sui tag