Should passwords be automatically reset when the underlying method changes

Question

I'm currently an engineer on a project in development phase. One 'module' on this project gives the ability for user authentication/authorization. However it's come to our concern that the password hashing algorithm may not be up to cop (aka not BCrypt). (The terrible thing is not quite sure what it is and where it came from!).

This obviously has to change and the patch is being scheduled. We have to naturally update all our test users because their passwords will be using the old hashing method, not much of a problem, all our demo users are automated on build so it's updating the script. But the next question is what if this is a production system with active and stale users, of all amounts. What would be best practice.

1. Automatically force a password reset on every user? This will notify every user that their password has been changed and may cause question/confusion and may cause suspicion that there's been a security breach. More questions may be asked which may not necessarily be able to be answered by website stakeholders.
2. Update the DB to flag whether it's the new or old method, then once a user has been authenticated update their password in the DB using. Requires a bit of logic in the service and transition will be seemless to any existing user. The problem being if there was a breach then it may be evident that there are two methods going on here and if the less secure one is found to be that insecure it could obviously be broken.
3. Reset all passwords, using a BCrypted version of the existing hash. Flag it as the old style, so on successful authentication it just keeps a hash of the password rather than a hash of a hash.

Answer 1

Your option 1. is a bad idea: in addition to the User-Experience / Public-Relations reasons you state, you're also giving attackers a window to intercept the password reset tokens and compromise every account on your server. It also doesn't solve your problem if you have even one user who's too lazy to log in / update their password.

At first glance, both 2. and 3. seem fine to me. Your #2 is no less secure than what you're doing now, but 2. would mean you have to continue supporting the current weak login forever (or do something like "After X months we're wiping your password and forcing you to do a recovery" which breaks the nice user-transparency you want, so let's ignore that).

Let's consider the case where you have users in the DB who will never log in again. With both 2. and 3. you have to continue to support the current hashing alg in your code-base forever just in case they do log in, but at least 3. has the advantage that they (or rather, you) are protected against offline brute-force attacks if your DB is ever stolen.

Since you'll have to keep the "old style flag" column around forever, do yourself a favour and make it an int not a bool so that if you ever have to update your password hashing alg again, you can record which old style they are on.

---

UPDATE: A very similar question was asked here and built on the discussion from this thread.

Answer 2

If you can do option 3, I don't see why you would even consider the others. It is by far the best option. With this option, my gut feeling would be to consider using two different salts, one for the old algorithm and one for the new one with bcrypt. I'm envisioning a set up like this:

1. Set up your new password system how you would if you were starting today.
2. Create a new separate table that has fields for username(or id), hashing algorithm (name or id), salt.
3. On login, check if the user has a record in the separate table, and if so, hash the password the old way, then hash the result the new way and compare with the bcrypt hash. If it matches, re-salt/hash the password the new way, and delete the record from the separate table.

The downside is you'll have to keep the password in memory a few milliseconds longer (who cares) and you'll have the extra table lookup on every login, pretty much forever, until either the separate table is empty or until old accounts become stale enough that you are willing to require them to reset their password themselves.

Answer 3

Note that, if your OLD scheme is hashed with salt, you will not be able to use scheme #3, unless you store the salt SEPARATELY.

Normally the salt is stored together with the hash, and you use the salt as input to the hash function - if you do not use exactly the same salt, you will get a completely different output.

If you newhash(oldsalt+oldhash, newsalt), then, even having the correct password, you will not be able to recreate oldhash (since you do not have oldsalt), and you cannot generate the final hash. Same thing applies to anything that has parameters (e.g. bcrypt has a "cost" parameter - this needs to be set when encrypting, and is embedded in the output, for use when validating the password).

ALSO: as was mentioned by others, if you are storing that the hash is "old" or "new" style, consider instead storing the "scheme" - where, e.g. 0 is the "old", and 1 is bcrypt (note I do not use "new" - it is "new" now, will not be "new" forever!). A common way to do this is to have a marker at the start of the hash (this may already be the case!). bcrypt uses one of the following standard prefixes: "$2a$", "$2b$", "$2x", or "$2y$". Depending on the possible outputs of your "old" algorithm, you may need to make up your own prefix to mark these, or you may be able to get away with 'anything that doesn't start with '$' is the old algorithm.

And finally, since you are obviously concerned (rightly so!) with the security of the old passwords, I would suggest forcing everyone to change their password, by emailing them instructions with a token (DO NOT! SEND A LINK! You do not want your users clicking on a link! Just tell them to log on to the usual place). Then, ask for the token AND their password. Otherwise, someone who has stolen a password in the past can change the password, and get a valid "new" password.

FINALLY: have an expiry date - if passwords are not changed by this date, then they should be invalidated. This date should be in the email, and not too far in the future (a week? depends on how long your customers take to respond). After that, they will have to go through "password reset" procedures.

Answer 4

I do not know what is your password encoding scheme, but if it not too bad, it is likely that the structure of the password in old and new format are different.

I have already seen something like that in an old BSD system when the system changed from a traditionnal password encoding to a more secure one. The new one started with a character sequence that could not exist in old scheme, so each time a user with an old password logged in, its clear text password was validated using the old method and silently re-hashed and stored back in password database with the new method. After one month, no old password was present in database, without end user noticing anything.

That would be somewhere in between your second and third method.

I know that in a real production web system, things can now be much worse, because users can wait weeks or even months before connecting again. But (depending on the real activity) it can be mitigated by the fact that a user that has not connected for several months can have forgotten its password - or you can tell him that he did... That means that I would wait a bit longer here probably 3 or 6 months and after that time I would reset all old style password to a forbidden value forcing the user to reset his password on next connection... through the forgotten password screen.

The nice things here are:

• transparent for regular users
• no database schema change - provided the password field can accept both styles
• occasional users will simply be handled as if they had forgotten their password after months without using it

The downside is that it forces you to simultaneously implement both authentication method + an automatic update of all style password.

Answer 5

You did not mention the language you are using. Php has its problems with various functions that should return false when it should return true in some cases, or other functions that sound like they do the job but lack the logic to actually handle the full possible valid possible inputs.

But this is the correct way to do what you are talking about in php even if you are not using php. The high level code can leave you with a starting point in coding it for your purposes.

http://php.net/manual/en/function.password-needs-rehash.php

$password = 'rasmuslerdorf';
$hash = '$2y$10$YCFsG6elYca568hBi2pZ0.3LDL5wjgxct1N8w/oLR/jfHsiQwCqTS';

// The cost parameter can change over time as hardware improves
$options = array('cost' => 11);

// Verify stored hash against plain-text password
if (password_verify($password, $hash)) {
    // Check if a newer hashing algorithm is available
    // or the cost has changed
    if (password_needs_rehash($hash, PASSWORD_DEFAULT, $options)) {
        // If so, create a new hash, and replace the old one
        $newHash = password_hash($password, PASSWORD_DEFAULT, $options);
    }

    // Log user in
}

What I would do would be your #2 with what has been mentioned with using an an int. From reading the documentation on the PASSWORD_DEFAULT it could change when better algorithms are found and they need to remove the current one for insecurity purposes as php is upgraded.

Answer 6

Advise the users regarding the security flaws in the old authentication system and suggest that they change/reset their password in order to use the new authentication system. If after a pre-decided period of time (which the users may be advised of in the "small print" somewhere) some users still haven't changed/reset their password, deactivate their account and send them an email instructing them on how to activate it again. This way, your regular users will feel like they are being "asked" to change their password, not "told" to change their password, so are unlikely to react negatively to the request even if they do change their password (which hopefully they will, if your advisory email is persuasive enough) and you won't have to support the old authentication system forever for the few users who never got round to changing their password.