That would sorta depends on the login infrastructure. To be fair, the systems I've written were only really designed to handle a couple dozen people, but would allow for expansion. What I did was do all the salting and hashing on the server side (since we forced the use of SSL, the password would never be sent on the wire in the clear, anyway). The password would be hashed twice (the old hash algo and the new one). If the old hash matched the value in the database, the user would be considered authenticated and the password hash field would be updated using the new algorithm. Over time, as users logged in, their passwords would be updated for the new hash.Ornette wrote:So they'll stick around until, along with the contingency, every one of your users have changed their passwords thus causing it to get hashed with the newer algorithm. And that's simply not something that's feasible with a large enough user base.
It's not the most secure solution, but if someone MITM'd us with SSLstrip or something, we would have bigger problems than a password breach. Namely, why someone is MITMing the sales application for a jewelry store. At that point, I had a contingency plan that would lock everyone out and set their password to a random number. Again, this was a small-time application.
