Come procedere se viene introdotto un nuovo algoritmo di hash per le password?

È vero che, poiché i buoni server non memorizzano mai password, solo password token di verifica (cioè hash), allora non possono cambiare la funzione hash senza la cooperazione dell'utente. Richiedendo agli utenti di immettere nuovamente la propria password, stanno dicendo che hanno già memorizzato le password in modo appropriato (o, almeno, non in modo orribilmente debole).

Tuttavia, chiedere agli utenti, tramite e-mail, di immettere nuovamente le loro password (seguendo le istruzioni in una successiva e-mail) è una pratica molto scarsa. Gli utenti dovrebbero essere addestrati mai a fare queste cose. Questa istituzione sta rovinando anni di sforzi educativi pazienti. Inoltre, non dovrebbe essere "istruzioni speciali": il processo di aggiornamento della funzione di hash dovrebbe essere automatico e trasparente al successivo accesso dell'utente. Trovo abbastanza sospetto che qualcosa di speciale debba essere fatto dagli utenti a quel punto - a meno che stiano pianificando di applicare una di queste temute "policy password" che rifiuteranno le password che non contengono lettere di entrambi i casi, cifre, segni di punteggiatura e due parole in sanscrito provenienti da diversi sūtra.

A mio parere, il modo corretto per aggiornare la funzione hash per l'hashing della password è farlo in modo trasparente per un lungo periodo (diversi mesi) e semplicemente per "bloccare" account che non sono stati utilizzati durante l'intero periodo. Se è necessario che gli utenti si connettano veramente in modo immediato, invia un'email indicando che "il tuo account non è stato utilizzato in 6 mesi, per motivi di sicurezza, sarà disabilitato se non ti connetti entro il mese successivo, e la riattivazione dovrà essere gestita attraverso l'helpdesk ".

@CodesInChaos suggerisce di "concatenare" gli hash, cioè utilizzando il vecchio valore di hash come "password" per il nuovo valore di hash, almeno in modo transitorio. Funziona e fornisce i vantaggi di sicurezza del nuovo hash a condizione che tutti i seguenti siano validi:

• il vecchio hash era "abbastanza decente" (ad esempio era un MD5 sulla password, non il vecchio hash basato su UNx DES che tronca le password a otto caratteri);
• hai un posto dove memorizzare i parametri extra (salt, conteggio iterazione ...) per il vecchio hash insieme ai parametri per il nuovo hash (o hanno lo stesso formato e possono quindi essere condivisi);
• sei pronto ad assumere il costo della CPU per calcolare entrambe le funzioni hash durante la verifica della password;
• se si esegue la transizione (ovvero si desidera che l'hashing della catena sia fino al prossimo accesso per questo utente), allora c'è un modo per contrassegnare l'hash memorizzato come "di transizione", in modo che il verificatore sappia che deve calcolare l'hash precedente quindi il nuovo hash.

Quindi dipende da cosa era la vecchia funzione, da quale è la nuova funzione e perché la si cambia. Incatenare gli hash è certamente una buona idea quando l'hash precedente è una semplice, non salta, invocazione non iterata di MD5 o SHA-1.

Sono d'accordo con Thomas. Non vi è alcuna giustificazione nel ricreare improvvisamente gli hash con un nuovo algoritmo. Tranne se ci fosse una perdita di database o una nuova vulnerabilità che rendesse reversibili gli hash.

Su una nota diversa, se non c'è altra scelta che cambiare immediatamente l'algoritmo, probabilmente è come lo faresti. Informi i tuoi utenti in modo che abbiano il tempo di verificarlo e di verificare che non si tratti di un tentativo di phishing. Quindi si imposta una piattaforma sicura per cambiare la password per tutti gli utenti. Certo, qualcuno potrebbe impersonare gli amministratori e inviare un'e-mail di follow-up con un indirizzo falso, ma la prima e-mail sembra cercare di educare le persone, non ci cascano, il colpevole è facilmente reperibile e le contromisure possono essere prese in modo efficace, rendendo così l'imitazione non redditizia.

Una buona politica è troppo forzare gli utenti a cambiare le loro password ogni 3 mesi circa. È un dolore, ma è considerato una buona pratica per una ragione, le persone tendono a usare la stessa password ovunque, o scriverla su un pezzo di carta o sul proprio telefono. Dato il tempo necessario, i rischi di compromissione di questi supporti diventano significativi. Nella mia azienda dobbiamo cambiarlo ogni 3 mesi, non possiamo usare una password vecchia e il nuovo dovrebbe essere abbastanza diverso da quelli più vecchi (cioè: non aggiungere un carattere ..).

È un dolore però, le password di solito sono così. Sono un grande fan dei Single Sign On (SSO) con token OTP. Facile revocabile, facile per l'utente, un solo supporto, ecc. Ma una tale infrastruttura ha un costo, rendendo la vita dei dipendenti un po 'più complicata cambiando le password regolarmente è una buona soluzione per il business.