Per il login attivo di un utente, è chiaro che è meglio utilizzare l'algoritmo più lento possibile con il minor numero possibile di collisioni al fine di impedire a un utente malintenzionato di accedere come un altro utente.
Quando si tratta di archiviare la cronologia delle password, la preoccupazione principale è proteggere il testo in chiaro della vecchia password dell'utente perché potrebbero ancora utilizzarlo in altri luoghi o utilizzare una password simile a quella corrente.
Penso che un hash MD5 o CRC troncato consentirebbe al sistema di controllare la cronologia delle password, anche se con occasionali falsi positivi (l'utente può solo pensare a qualcos'altro), ma renderli impossibili * da invertire. Quando dico impossibile, voglio dire che ci sarebbe stato collisione di testi in chiaro per design e che sarebbero indiscernibili dal testo in chiaro della password originale scelta dall'utente.
Se la cronologia delle password deve essere mantenuta, è un approccio pratico?
Un utente malintenzionato può cercare tra quelle collisioni cercando la password più probabile per l'input umano, forse cercando parole di dizionario o suffissi di tipo "1234".
Con collisioni abbastanza alte, quel tipo di restringimento sarebbe impraticabile? Forse hash metà della loro password?
Troppe collisioni dalla cronologia delle password potrebbero impedire troppe nuove password?