3 ms·
I have a genuine not rhetorical question. Use brcypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
by 6cxs2hd6 13y ago
I have a genuine not rhetorical question.
Use brcypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
Am I correct that this advice wasn't obvious in the early years of Drupal.org?
If so, what ought a site like Drupal.org do, today? Should they update the password storage to use bcrypt, and require all users to update their passwords? i.e. Proactively do in a constructive way, what they'd otherwise need to do in a crisis mode?
If so, why don't more sites do this? Is it ignorance? Inertia? Or concern that they'll lose users who can't be bothered?
- mambodog 13y agoWhen moving from a weak password hashing scheme to a stronger one you can keep old passwords around and just hash them again with the new system (that is, run your existing hashes through your new hashing function), and mark them as using the twice-hashed scheme. Your password comparison function can have a special case to use the twice-hashed scheme when comparing passwords on login. Users are migrated to the new scheme upon updating their password. This is the approach which Drupal supports for migrating from Drupal 6 (which uses unsalted MD5) to Drupal 7 (salted SHA-512).
- 6cxs2hd6 13y agoSo if I understand correctly, they could use the same approach when updating to do what they really ought to -- use bcrpyt? As a result the very oldest pwds would be thrice encoded -- from unsalted MD5 to salted SHA-512, and run that through bcrpyt?