3 ms·

> re-hash user passwords using something stronger than MD5 Isn't this only possible if you do it on user login - unless you are also cracking user passwords...

by kibibu 12y ago

> re-hash user passwords using something stronger than MD5 Isn't this only possible if you do it on user login - unless you are also cracking user passwords... Actually has anybody cracked their own MD5 user passwords to upgrade them?

rosser 12y ago
You might be right. It was a while ago that we did that, and I may have conflated it with another bulk update of our "users" table. Either way, I've used this idiom at least half a dozen times in production, all without any downtime or user-visible effect, and we have millions of orders, SKUs and users.
bradleyjg 12y ago
You can sort of upgrade hashes in place at the cost of extra book keeping. Take the old hash, and use it as the input to a new stronger hash. Mark some column to indicate you've done this. Then next time the user logs in, you calculate the old hash and then the new hash from that. Once you validate the password use it to calculate a new new hash, put that in the field and clear the update column.
- reitzensteinm 12y ago
  You don't even really need the book keeping - you can update the hash in place as you say, then just try both eg bcrypt . password and bcrypt . md5 . password. It would be even simpler to style all future passwords as bcrypt . md5 . password but I'm not sure of the security implications of that as a permanent measure and so wouldn't do it personally.
  - bradleyjg 12y ago
    Security wise bcrypt(md5(password)) is at least as strong as bcrypt(password). However broken md5 is it is certainly no easier to find a preimage than where you already have the preimage. (Edit: now that I think about it, it could be worse if there is a side channel in your md5 implementation.) If you do it that way you'll pay a performance cost on every password check forever. I suppose that trade-off might worth it in some cases.
    - Xorlev 12y ago
      So much of password hashing is a deliberate performance cost anyways, it almost hardly matters if your password passed through md5 and sha{1,2}. bcrypt will eclipse them all in relative cost, as it should be.
- ctz 12y ago
  This is exactly what facebook do. They've done it several times over, such that a plaintext password goes through about 8 steps before making it into a database.

by kibibu 12y ago

rosser 12y ago

You might be right. It was a while ago that we did that, and I may have conflated it with another bulk update of our "users" table. Either way, I've used this idiom at least half a dozen times in production, all without any downtime or user-visible effect, and we have millions of orders, SKUs and users.

bradleyjg 12y ago

You can sort of upgrade hashes in place at the cost of extra book keeping. Take the old hash, and use it as the input to a new stronger hash. Mark some column to indicate you've done this. Then next time the user logs in, you calculate the old hash and then the new hash from that. Once you validate the password use it to calculate a new new hash, put that in the field and clear the update column.

reitzensteinm 12y ago
You don't even really need the book keeping - you can update the hash in place as you say, then just try both eg bcrypt . password and bcrypt . md5 . password. It would be even simpler to style all future passwords as bcrypt . md5 . password but I'm not sure of the security implications of that as a permanent measure and so wouldn't do it personally.
- bradleyjg 12y ago
  Security wise bcrypt(md5(password)) is at least as strong as bcrypt(password). However broken md5 is it is certainly no easier to find a preimage than where you already have the preimage. (Edit: now that I think about it, it could be worse if there is a side channel in your md5 implementation.) If you do it that way you'll pay a performance cost on every password check forever. I suppose that trade-off might worth it in some cases.
  - Xorlev 12y ago
    So much of password hashing is a deliberate performance cost anyways, it almost hardly matters if your password passed through md5 and sha{1,2}. bcrypt will eclipse them all in relative cost, as it should be.
ctz 12y ago
This is exactly what facebook do. They've done it several times over, such that a plaintext password goes through about 8 steps before making it into a database.