That's easily handled by, say, a column in a database table. Or just use something that's very unlikely to need replacing, like bcrypt. As far as I know, the only people who really needed to switch password hashing schemes in a hurry were people who chose laughably broken ones to begin with. (Hint for people who don't know this yet: salting and SHA256ing is an example of such a laughably broken password hashing scheme, so you can save yourself the hassle of migrating away from it by not using it in the first place.)
Doing a column in the database is exactly what I suggested... Also, saying that anything is "very unlikely to need replacing" is extremely short sighted of you. And the point is not to necessarily do it "in a hurry" but rather to identify a mechanism for doing it at all, in a way that doesn't require resetting every user's password.
I misspoke -- I meant to say "very unlikely to need replacing soon." Look at SHA-1, for an example of this sort of thinking -- there have been some security problems found with it, and SHA-2 is recommended for anything new, and there's a contest to determine what algorithm will be SHA-3, but people who are using SHA-1 are not in dire peril. It's the "walk, don't run, to the nearest exit" approach to security. You pick something strong and hope that, if attacks are found against it, this process will be gradual enough that you'll have plenty of time to build the infrastructure needed to support migration, and migrate.
I just think that starting out planning for password hash function migration, when it's easy to retrofit later, is a bad case of premature optimization.
I do not see this as premature optimization. Do you store timezone information with your dates even if you are not operating in a different time zone? Do you store measurement information with a unit even if you love inches? I would say that it is certainly planning ahead, but it is not a premature optimization. It is planning for the all-to-likely event that you will need to start hashing your passwords in a different way.
"when it's easy to retrofit later" - I think this is the key part of your statement. When is it easy to retrofit later? You then have to pick your poison:
1. Switch entire system over to new hashing function - reset all user's passwords
2. Add in interoperability of hashing functions - what I'm suggesting you do from the beginning, making it much easier to do.
Number 1 is a horrible user experience, number 2 is much easier to do from the onset.
When you decide to do a new password storage function:
New users get the new hash right away.
Calculate the new hash and the old hash when the user next logs in.
If the old hash matches, the user has logged in, and now calculate the new hash and store it over the old hash in the table. Perhaps make a note in a separate column that the hash has been converted.
Eventually, when all users have refreshed their passwords, quietly remove the old way.
When I say "Add in interoperability of hashing functions", that is pretty much exactly what I mean. I realize I left out the specific method for converting the hashes over. And your separate column for when the hash has been converted is the equivalent of my suggesting for a HashVersion column. Also, you will likely never be able to "quietly remove the old way" because not all of your users are guaranteed to log in again. But yes, the idea would be to verify against the old hash, save the new hash when the user logs in.
I'm not sure how number 2 actually helps with security. If the hashing method is deemed insecure enough to stop using, would you not want to update all your users passwords stored in db to using a newer method? One method of doing so without having to reset passwords was posted: http://news.ycombinator.com/item?id=4083883 .
I would only say that you would want to immediately reset all user passwords if the passwords were leaked, not necessarily if the algorithm that you are using is bad for whatever reason. And the idea would be to give users a couple weeks (or days) to log in and then force the reset on all the remaining(maybe once you get to a certain percentage of your active user base).
I like the method that link provided, but there are some drawbacks, needing to update every user record with a new hash (offline process) - this is almost guaranteed to require taking the site down, which most people do not like to do. This is because you can't have some users with the old hashing process ,and some with the new.
The nice thing about bcrypt is that it stores the work factor and salt and hash all in one value, so you can very easily migrate to harder work factors. I have seen similar schemes used to store hashes from a variety of algorithms, you can simply have something like bcrypt$workfactor$salt$hash stored in the password field.
Yes, storing the algorithm used in the same column would be fine as well. But if you drop the "bcrypt$" from your example, you would still run into issues if bcrypt itself is broken.
Sure - but the idea of salting is to make the dictionary too time consuming to create. The security is NOT in how secret your methods are (it rarely is).
Additionally, each salt is still unique per password, so the attacker would need to generate a full dictionary per record that they want to crack - generally not worth it.
There is a chance that if your DB is compromised, your code is as well. Additionally, what if you want to change your work factor, how would you handle doing that? If you upgrade your server environment and then all of a sudden realize that your hashing algorithm only take .1 seconds, when it used to take .5 you might want to change it.
While that may slow down an attacker in some circumstances, a sufficiently secure password scheme will still be secure with total knowledge of the system available to the attacker. See also: security through obscurity.
