5

Suppose BigBusiness™ Inc. Ltd. built a web service in 1995, storing their user passwords using bleeding-edge technology: unsalted md5 hashes. Now they realize that this was probably a bad idea and want to increase the security of their users in case of a breach without forcing a password reset on everyone. So they decide to store PBKDF2(old_hash, individual_salt) instead.

Is this a good strategy or does it have any drawbacks?

Improve this question
2
  • I don't see any problem with this approach. It was a good idea at the time, I actually stored passwords in clear-text in 1995! The only bad thing is that they waited until 2016 to change this.
    – Peter Hahndorf
    Sep 23, 2016 at 16:51
  • Hopefully these aren't "very VIP" accounts (thanks for not saying more).
    – Adam Katz
    Sep 27, 2016 at 19:36

2 Answers 2

Reset to default
2

Well, I'd suggest BCrypt over PBKDF2.

That being said, your solution should be two-fold.

  1. To secure the system immediately, yes your solution is good. Treat the MD5 as the input password, and have per-user salt as you suggest.

  2. I would suggest migrating MD5 out of the picture. (unless this is strictly legacy application)

    Next time the user signs in, your application will have access to the unhashed password, and will have the ability to update the hash with one that skips the MD5 step. You'll have to have some indicator on the account as to whether this has been completed.

I would also recommend pre-pending Pepper to the input password (or MD5) as an additional security precaution.

BCrypt has a max length on passwords, so it is best to place the input password combined with Pepper in an SHA-256 hash first. I'm not sure if PBKDF2 has this limit. Eventually you may one day use an even newer hash that does not have this limit either.

You know, really, migrating off of MD5 is probably not necessary, but getting rid of MD5 would be the ideal solution for best collision resistance and just seems like a cleaner design.

Improve this answer
4
  • 1
    PBKDF2 has no length limits unless the digest algorithm that it's using has one. Neither MD5 (which isn't ideal for anything, but can be used for PBKDF2 if you've got legacy code) nor any of the SHA* functions have a limit on input length.
    – CBHacking
    Sep 23, 2016 at 20:17
  • Thanks. That is why I suggest using SHA-256 if he uses BCrypt, but actually if the OP continues to use MD5 (accepting the small risk of collision) then SHA-256 is not necessary.
    – 700 Software
    Sep 23, 2016 at 20:29
  • 2
    @CBHacking: actually SHA1 and some SHA2s are limited to slightly less than 2^64 bits which is 2 exabytes, more than anybody but probably NSA and Google has enough disks to store,. and the other SHA2s are nearly 2^128 bits which is far far more than all digital storage on Earth, so these are no problem in practice. MD5 is not limited at all (because people didn't care then) and neither is SHA3 (because of its new design).
    – dave_thompson_085
    Sep 24, 2016 at 8:17
  • @dave_thompson_085: Interesting; thanks! I'm pretty sure nobody is throwing around multi-Exabyte passwords, but thank you for the correction.
    – CBHacking
    Sep 24, 2016 at 19:29
1

As George says, this system is fine for now (assuming you use good salts and a good iteration count for PBKDF2). However, you need to add flexibility to the system to account for future updates to the password verification algorithm. While your current scheme has the advantage that you can update the password verifier security without needing the actual password, it's still a good idea to have a value that lets you see what the algorithm for a particular verifier is.

Times you might need this:

  1. If you do some verifier update that can't be done based just on the old verifier, you won't be able to process each password until the user logs in, so you'll have some password verifiers using the new algorithm and some using an older one.
  2. If you have to restore from a backup, it's good if your authentication code can recognize and support legacy verifiers. Saves you from needing to ensure you're using the right version of your codebase to match with when the auth DB was backed up.
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.