10

I'm working on an Intranet project that is accessible from the outside. The password are stored in a Sql Server database in the normal Hash and salt method. The problem lies in the hashing algorithm.

It currently use SHA512Cng and we can't find the decision behind why this algorithm was used. I would like to upgrade this hashing algorithm to use bcrypt as well as making the salt key longer.

Of course, since the passwords are hashed, we just can't run a batch to upgrade the password.

What are the possible path available when upgrading an authentication method from a less secure one to a more secure one of a live database?

Of course, we would like the database to remain as secure as the SHA512Cng method currently provide and not compromise the database during the upgrade process.

Improve this question
1
  • 6
    The simple solution would be to bcrypt the current hash. When new passwords are created just perform a bcrupt( SHA512CNG( password ) ).
    – Ramhound
    Jul 16, 2012 at 18:14

4 Answers 4

Reset to default
11

Hash the hash, then update as users successfully authenticate or update their passwords. This way you have immediate security, which is the main point of your endeavor.

Implementation:

Hash and save in place all of the SHA hashes in your db w/ bcrypt, so you only have bcrypt hashes. When users authenticate, you check for equivalence w/ bcrypt(password). If that fails, you then compare against bcrypt(sha512(password)). As users authenticate successfully and/or update their passwords, you hash the password w/ bcrypt.

The main tradeoff is that you have to maintain a couple of extra lines of code (the secondary hash comparison). But this is much better than maintaining a second password column while keeping around insecurely hashed passwords.

EDIT: Argh! Posted before noticing that Ramhound replied w/ the same idea in a comment to the question. Agree w/ him.

Improve this answer
3
  • Why not just leave it bcrypt(sha512(password)) forever? Is there a benefit in migrating over to only bcrypt?
    – Wilka
    Jul 17, 2012 at 20:22
  • I selected this answer because I like the way the database is immediately more secure instead of having an overtime conversion.
    – Pierre-Alain Vigeant
    Jul 19, 2012 at 14:46
  • 1
    @Wilka "Don't roll your own crypto" applies here. Combining the hash algorithms may introduce unknown vulnerabilities. The reason to rehash is because the old algorithm is so weak it offers little to no protection. The combination is unlikely to be less safe than the old hash alone, and you are hoping it is somewhat more safe than the old one. If the old algorithm isn't extremely weak (e.g., you're going from bcrypt to scrypt), you don't want to bother with this.
    – jpmc26
    Jun 23, 2016 at 20:53
13

I recommend incrementally switching each user over to the new password hashing method on their next login. At that point, you know their cleartext password, so you can re-hash it with bcrypt and switch them over to bcrypt. This avoids the need for a "flag day" or contacting all your users. In fact, it is invisible to users: your users never need to know you are transitioning to a new password hash algorithm.

In more detail:

  • Add another field to the database to indicate which kind of hashing algorithm was used to compute the password hash. In other words, there are two fields associated with each user: one for the password hash, and to indicate the hashing algorithm (SHA512Cng or bcrypt). Initially, password hash algorithm for every user is initialized to SHA512Cng.

  • When a user tries to logs in, look up the password hash algorithm for their account, hash the password they provided using that algorithm, and compare it to the stored hash. If it does not match, the login is rejected. If they do match, the login is accepted.

  • Additionally, if the login was accepted and if the algorithm in the database is SHA512Cng, then re-hash the password using bcrypt, overwrite the password hash with the new bcrypt hash, and change the algorithm in the database to bcrypt.

This allows you to gradually transition to the new password hash algorithm, as people log into your service.

Optionally, after a few months have passed, if there are any users who haven't logged in (and thus still have their passwords hashed with SHA512Cng), you could reset their password or email them and request them to log in again or something. However, in many cases this may not be necessary.

P.S. Or, you could use Ramhound's elegant solution of simply bcrypting the password hash. Clever!

Improve this answer
1
  • +1 For after a certain time just resetting the password, this way you minimize the number of users that you inconvenience but have a definite date when your database has transitioned.
    – Andy Smith
    Jul 17, 2012 at 16:41
2

The generic method is to use a transitory period during which both old and new hash methods are used; this requires being able to distinguish hashes of both types in the database. The hash method can then be upgraded from the old to the new at the next login from the user. You can possibly nudge gently the users so that they log in within the next few months; alternatively, you could disable the accounts of people who have not logged in for six months. See this question for some details.

Still during the transition period, you can chain hashes: use the old hash value as the "password" for the new one. If the old function is a plain, unsalted hash of the password, then this will be easy. If the old function used a salt, then you need to keep it along with the new salts for the new function.

Ideally, you would have used a hash function which was salted and iterated, and such that extra iterations can be added without needing the original password. To my knowledge, there exists no widespread password hashing function which supports that, although I see no immediate impossibility (cryptographers still have work to do).

Improve this answer
1

The usual method is to contact the users to let them know they will need to login, say within the next month, then when they do, upgrade the hashes at that point.

This way you aren't needing to do anything other than confirm the user's old password hash when they log in, and store the hash of the new password.

All you need is to track which users have upgraded, and remove the old hashes.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.