A lot of documents on the web related to Rfc2898DeriveBytes suggest that the number of iterations should be increased every two years. I am designing a new database structure for an application to contain the number of iterations with the hash and salt for each user. What is the best way of ensuring that all passwords are updated to the new iteration count in two years? Rfc2898DeriveBytes constructors only accept password as input, not hash. I'm a bit cautious about writing my own function, but would rehashing with HMACSHA1 be an option? Or do I just need to wait for all users to log in and rehash them if they have the old iterations?
1 Answers
Or do I just need to wait for all users to log in and rehash them if they have the old iterations?
Yes, that is the normal solution.
You run the function once passing in the user provided password, the saved salt, and the saved iteration count. Once you verify that the hashes match you compare the iteration count the user has to your global iteration count you use for new passwords. If the old count is lower you run the function again using the user provided password, a new salt1, and the new higher iteration count. You then update the hash, salt, and iteration count you have saved for that user.
To enforce the update you just have a variable in a config file on the server that you change every two years. That gets loaded to the global iteration count you use for new passwords when the program restarts after a config change. As people log in they get the new iteration count.
1: you don't have to do a new salt, but it does not hurt anything to do it.