9

This question already has an answer here:

I'm currently dealing with a couple of user accounts containing MD5 hashed passwords. These accounts got migrated from an old system into our current system which uses PBKDF2 for password hashing. I would like to lift the old accounts to PBKDF2 password hashing as well.

Cracking our own MD5 hashes and rehashing them with PBKDF2 is out of the question.

The first thing that came to mind was migrating the user passwords at login, as described here.

However, I would never be able to migrate all user passwords because some of the users might never return and thus never login again, leaving me forever with insecure hashes.

So two options are left:

  1. Resetting all passwords and informing the users via email
  2. Hash the MD5 hashes in the database again with PBKDF2 and use this double hashing when a "legacy user" logs in. Meaning PBKDF2(MD5(plaintext)).

First solution would be really unpleasent for the users, because they would have to set a new password, so I'm tending towards the second solution. This seems to support this approach, although talking mainly about bcrypt and not PBDKF2

Is wrapping MD5 in PBKDF2 (or, for what it's worth, other secure hashing algorithms) something that safely can be done, or are there better approaches for dealing with old, insecure MD5 hashes?

marked as duplicate by Anders, Matthew, martinstoeckli, Community Jun 17 '16 at 17:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    How about a combination approach - have a defined time period where you migrate at login, then reset any passwords that haven't been changed during that period. That way, you get the benefits of secure hashes for regular users as soon as they log in, and of reminding other users to log into your service. – Matthew Jun 17 '16 at 8:00
  • I guess it might be beneficial to split it into two questions. One about the practical side and possibilities of transition, the other purely theoretical if "processed" hashes pose a security risk. – techraf Jun 17 '16 at 8:29
  • Also relevant: security.stackexchange.com/questions/119680/… – Anders Jun 17 '16 at 9:21
  • Thanks @Anders. That actually fits quite well so i think this can be safely marked as duplicate – concerned citizen Jun 17 '16 at 17:34
7

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately.

Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried to explain it in this answer.

  • 1
    Nice point, very important reminder that while not insecure, it could be insecurelly implemented! – CristianTM Jun 17 '16 at 13:41
7

Is wrapping MD5 in PBKDF2 (or, for what it's worth, other secure hashing algorithms) something that safely can be done, or are there better approaches for dealing with old, insecure MD5 hashes?

Yes, it is secure. You do not lose any security on this process. All these passwords would experience the same protection that the non-MD5 passwords have, given by PBKDF2 - one could say with some extra (weak and mostly non relevant) added md5 "security".

On login you could "drop" the md5 hash, re-calculating PBKDF2 without MD5 and storing it after successful login. That way you would not need to keep the md5 check "forever".

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