Come aggiornare il metodo di hashing di un database live senza compromettere la sicurezza?

Hash hash, quindi aggiorna mentre gli utenti autenticano o aggiornano correttamente le loro password. In questo modo hai una sicurezza immediata, che è il punto principale del tuo sforzo.

Implementazione:

Hash e salva tutti gli hash SHA in db w / bcrypt, quindi hai solo hash bcrypt. Quando gli utenti si autenticano, controlli l'equivalenza con bcrypt (password). Se ciò non riesce, si confronta quindi con bcrypt (sha512 (password)). Man mano che gli utenti si autenticano e / o aggiornano le loro password, si hash la password con bcrypt.

Il compromesso principale è che devi mantenere un paio di linee extra di codice (il confronto hash secondario). Ma questo è molto meglio che mantenere una seconda colonna password mantenendo le password con hash insicuri.

EDIT: Argh! Pubblicato prima di notare che Ramhound ha risposto w / la stessa idea in un commento alla domanda. D'accordo con lui.

Raccomando di passare gradualmente ogni utente al nuovo metodo di hashing della password al successivo accesso. A quel punto, conosci la loro password in chiaro, quindi puoi re-hash con bcrypt e cambiarli in bcrypt. Ciò evita la necessità di un "flag day" o di contattare tutti i tuoi utenti. In effetti, è invisibile agli utenti: i tuoi utenti non devono mai sapere che stai passando ad un nuovo algoritmo di hash delle password.

Più in dettaglio:

• Aggiungi un altro campo al database per indicare quale tipo di algoritmo di hash è stato utilizzato per calcolare l'hash della password. In altre parole, ci sono due campi associati a ciascun utente: uno per l'hash della password e per indicare l'algoritmo di hashing (SHA512Cng o bcrypt). Inizialmente, l'algoritmo di hash delle password per ogni utente viene inizializzato su SHA512Cng.

• Quando un utente prova ad accedere, cerca l'algoritmo hash della password per il suo account, hash la password che hanno fornito usando quell'algoritmo e la confronta con l'hash memorizzato. Se non corrisponde, l'accesso viene rifiutato. Se corrispondono, l'accesso è accettato.

• Inoltre, se l'accesso è stato accettato e se l'algoritmo nel database è SHA512Cng, re-hash la password utilizzando bcrypt, sovrascrive l'hash della password con il nuovo hash bcrypt e modifica l'algoritmo nel database in bcrypt.

Ciò ti consente di passare gradualmente al nuovo algoritmo di hash della password, poiché le persone accedono al tuo servizio.

Facoltativamente, dopo alcuni mesi, se ci sono utenti che non hanno effettuato l'accesso (e quindi hanno ancora hashed le loro password con SHA512Cng), puoi reimpostare la loro password o inviarli via email e richiederli di accedere nuovamente o qualcosa. Tuttavia, in molti casi questo potrebbe non essere necessario.

P.S. Oppure, è possibile utilizzare l'elegante soluzione di Ramhound semplicemente crittografando l'hash della password. Clever!

Il metodo abituale è contattare gli utenti per far sapere loro che dovranno effettuare il login, ad esempio entro il mese successivo, quindi quando lo fanno, aggiorna gli hash a quel punto.

In questo modo non devi fare altro se non confermare l'hash della vecchia password dell'utente quando accedono e memorizzare l'hash della nuova password.

Tutto ciò di cui hai bisogno è tracciare quali utenti hanno aggiornato e rimuovere i vecchi hash.

Il metodo generico consiste nell'utilizzare un periodo transitorio durante il quale vengono utilizzati i metodi hash vecchi e nuovi; ciò richiede la possibilità di distinguere gli hash di entrambi i tipi nel database. Il metodo di hash può quindi essere aggiornato dal vecchio al nuovo al successivo accesso dell'utente. Puoi eventualmente spingere gentilmente gli utenti in modo che accedano entro i prossimi mesi; in alternativa, è possibile disabilitare gli account di persone che non hanno effettuato l'accesso per sei mesi. Vedi questa domanda per alcuni dettagli.

Ancora durante il periodo di transizione, puoi chain hashes : usa il vecchio valore di hash come "password" per quello nuovo. Se la vecchia funzione è un semplice hash non salato della password, allora sarà facile. Se la vecchia funzione utilizzava un sale, devi mantenerlo insieme ai nuovi sali per la nuova funzione.

Idealmente, avresti usato una funzione di hash che è stata salata e iterata e tale che è possibile aggiungere ulteriori iterazioni senza la password originale. Per quanto ne so, non esiste una funzione di hashing della password diffusa che supporti ciò, anche se non vedo un'impossibilità immediata (i crittografi hanno ancora del lavoro da fare).