Aumenta la sicurezza di un hash delle password già memorizzato

Costruire il proprio algoritmo è mai una buona idea. Anche i crittografi addestrati, cioè le persone che hanno faticato per anni nelle oscure gallerie del mondo accademico e nei campi di battaglia del congresso scientifico, ricorreranno a tale inventiva solo quando tutto il resto ha fallito; e anche allora, preferiscono suggerire schemi che devono essere convalidati dai loro coetanei feroci, di sicuro non essere messi subito in produzione. La maggior parte della formazione accademica riguarda l'acquisizione di una conoscenza intuitiva dei pericoli del proprio campo.

La progettazione del tuo algoritmo è come il tap-dancing in un campo minato.

Tuttavia, l'impossibilità di estendere semplicemente il numero di iterazioni di un hash memorizzato, a partire dal valore hash stesso, è un difetto noto dei soliti candidati (PBKDF2, bcrypt e scrypt). Se devi conviverci, puoi provare lo schema descritto lì , ma neghiamo esplicitamente che la sicurezza sarebbe aumentata in questo modo. La mia formazione e anni di esperienza nel settore mi consentono di affermare con una certa sicurezza che i turni di hashing in più suggerisco di non ridurre la sicurezza.

In futuro, le cose andranno meglio perché una nuova competizione aperta per algoritmi di hashing della password è stata lanciato, utilizzando il modello delle precedenti competizioni AES, eSTREAM e SHA-3. La presentazione è prevista per la fine di gennaio 2014. Un portafoglio di "buoni algoritmi" sarà ottenuto entro la metà del 2015, secondo la tempistica provvisoria. La richiesta di invio include esplicitamente la seguente funzionalità desiderata:

Ability to transform an existing hash to a different cost setting without knowledge of the password.

Quindi possiamo sperare in una soluzione al tuo problema tra poco più di due anni. Solo due anni, è molto veloce per gli standard di progettazione crittografica.

Nel frattempo, dovrai ricorrere al consueto sistema di attesa per l'accesso degli utenti in modo che la loro password possa essere modificata con più iterazioni. La maggior parte degli utenti che non hanno effettuato l'accesso per più di un anno hanno probabilmente dimenticato la password comunque.

La soluzione classica è quella che scrivi alla fine - "rihash la password [..] quando l'utente effettua il login". In altre parole:

1. L'utente accede, presentando la sua password in testo semplice.
2. Il sistema blocca la password usando il vecchio hash e la confronta con il valore memorizzato.
3. Se corrispondono, cancella la password in chiaro con il nuovo algoritmo di hashing più strong e scrivi il risultato nel database.
4. Per gli account che non effettuano l'accesso entro un determinato periodo di tempo, invia loro un'e-mail cortese chiedendo loro di visitare nuovamente il sito, altrimenti il loro account verrà rimosso.

Detto questo, fai attenzione a non esagerare con l'hashing delle password. Lo scopo principale dell'hash delle password è ritardare l'attaccante nello sfruttamento delle password dopo una violazione riuscita - consentendo agli utenti finali di cambiare la propria password. Ad un certo punto l'hashing della password diventa "abbastanza buono" rispetto agli altri componenti nel sistema.

Ovviamente, evitare che l'attaccante possa violare il sistema in primo luogo è la cosa migliore, quindi mantieni abbastanza energia per il continuo processo di costruzione e manutenzione di sistemi sicuri. (Come verifiche di sicurezza del codice in corso, manutenzione del set di regole di Web Application Firewall, monitoraggio e configurazione del sistema di rilevamento delle intrusioni, protezione dei supporti di backup, ecc.)

Ho avuto lo stesso requisito e l'ho risolto in questo modo:

• Hash il sale e la password nel solito modo con PBKDF2 e un fattore di lavoro che è attualmente 16 (cioè 2 ^ 16 iterazioni). Memorizza il sale, l'hash, il fattore di lavoro, ecc. Come una riga in una tabella di database.
• In modo asincrono (ovvero non influisce sull'utente finale) fallo altre 3 volte, aumentando il fattore di lavoro di 1 ogni volta. Così ora ho 4 file di database per quell'utente, con fattori di lavoro rispettivamente di 16, 17, 18 e 19
• Uso sempre la riga con il fattore di lavoro più basso per verificare la password, ma ogni 2 anni elimino la riga con il fattore di lavoro più basso.