spostandosi da MD5 a SHA-512

Ho dovuto risolvere lo stesso problema due volte prima:

1. La mia prima app Web, in realtà ne sapevo abbastanza per le password degli utenti hash MD5; Tuttavia, non sapevo di sale, e ho lavorato in seguito.
2. In realtà la stessa app web, alcuni anni dopo, quando ho deciso di "aggiornare" a SHA-512 dal MD5 esistente.

In entrambi i casi, non ho usato nessuna delle opzioni, ma piuttosto l'opzione 3: al successivo accesso di un utente, utilizzare la password per generare il nuovo hash e sostituire quello vecchio (dopo averlo verificato rispetto a quello precedente).

Nel caso di aggiungere un salt, questo è stato piuttosto banale: tutto ciò che ho fatto è stato il default di tutti a un "" (stringa vuota), che potrebbe essere concatenato e quindi hash senza alcun effetto sull'hash risultante; una volta autenticato, ho generato un nuovo salt per l'utente e quindi re-hash la password, salvando il nuovo risultato.

L'aggiornamento da MD5 a SHA-512 era un po 'più complicato, ma osservando semplicemente la lunghezza della stringa dell'hash nella tabella (non ho usato una nuova colonna per il nuovo hash, semplicemente espanso quello esistente per ospitare l'hash più lungo) potrei dire quale algoritmo usare e quindi autenticare l'utente in modo appropriato; una volta autenticato, se fossero ancora sul vecchio hash, ne calcolerei uno nuovo (cogliendo anche l'opportunità di generare un nuovo sale) e memorizzarlo.

In entrambi i casi, naturalmente, alla fine ho incontrato la situazione in cui ancora esistevano le parole d'ordine "vecchio stile". Dopo aver atteso un intervallo di tempo appropriato (ad esempio 6 mesi), è sufficiente decidere che quelli che non hanno effettuato l'accesso da quando il nuovo stile è stato adottato sono "inattivi": generare e memorizzare una nuova password completamente casuale per loro (utilizzando il nuovo stile di memorizzarlo, ovviamente), e se mai sono tornati avrebbero dovuto usare il meccanismo di reset della password per riottenere l'accesso. (In alternativa, lasciare così com'è, ma efficacemente invalidarlo semplicemente rilasciando il codice per il vecchio stile.) Si potrebbe (se applicabile) anche inviare una e-mail a questi utenti, chiedendo loro di accedere per completare un aggiornamento di sicurezza su il loro account, prima di invalidare la loro password corrente.

Questo approccio comporta un codice aggiuntivo nella routine di autenticazione, ovviamente, ma è solo temporaneo - una volta che tutti sono stati aggiornati (sia effettuando il login o "forzati" come nel paragrafo precedente), puoi rimuovere tutto codice responsabile per l'esecuzione dell'upgrade. Aggiornamento della sicurezza completato, con la maggior parte dei tuoi utenti (e tutti i tuoi utenti abituali) che non hanno mai notato nulla!

Ho già usato l'opzione 2 in una società che ha bisogno di fare la stessa cosa. Nessun problema con l'opzione 1, ma 2 sembra più semplice.

Utilizza anche PBKDF2 , bcrypt al posto di SHA-512 per le password

Ok Open-ID non è disponibile ma puoi usare O-Auth e usare qualcosa come Twitter o Facebook per connetterti ed eliminare completamente la memorizzazione e la gestione di nomi utente e password?

Questa non è una risposta vera in quanto non affronta la tua domanda specifica, ma concordo con l'aggiunta di un'altra opzione per federare i tuoi ID. Quindi, sia che si tratti di OpenID, Facebook, Google, chiunque ... l'opzione migliore per archiviare in modo sicuro le credenziali dell'utente è semplicemente non farlo.

TL; DR: autenticazione federata se / dove possibile.

Non fare l'opzione 1, perdi tutti i vantaggi dell'algoritmo di hashing migliore. Con hashing con un algoritmo peggiore prima, poi con uno migliore:

• Si perde tutta la resistenza di collisione di sha512. Se md5(password1) == md5(password2) , quindi sha512(md5(password1)) == sha512(md5(password2)) . Non sono un ricercatore per la sicurezza, ma dal momento che esegui l'hashing più volte, sospetto che aumenterai le possibilità di una collisione (possibilità di collisione di md5 + possibilità di collisione con sha + md5)

• I bit extra (512 vs 128) sono inutili per lo stesso motivo. L'hashing di 128 bit di informazioni non ti darà mai più di 128 bit di entropia.