[jharding]

If you're storing passwords as MD5/SHA hashes, how difficult is it be to switch over to bcrypt? I've never had to do this, but I would imagine it would be somewhat trivial. With all of the password leaks that have happened over the past few years, I'd imagine a good amount of developers are aware that storing passwords as MD5/SHA hashes is somewhat risky, so I can't understand why big websites (LinkedIn) are still doing it.

[ammmir]

if your userbase is fairly active, you could migrate passwords the next time they login (and store a flag indicating the password "version"), since you'd have the plaintext version during authentication time.

alternatively, you could bcrypt all hashes now, and anytime you authenticate, making sure to MD5/SHA hash the plaintext password before checking the password using bcrypt.

legacy code and especially authentication code that has huge exposure (code path hit during every login and potentially every session auth) is difficult/risky to change once deployed. making things "more secure" has always been a hard sell to management... until a disaster like this happens!

[kmfrk]

In Django, as I recall, you just check for a hashing indicator that's prefixed to the hashed password, and do something like this on a user's log-in:

    if hashed_password.startswith("sha$"):
        hashed_password = bcrypt(hashed_password)

(or `... = "bc$" + bcrypt(hashed_password)`. However it's done.)

Here is the relevant code for django-bcrypt: https://github.com/dwaiter/django-bcrypt/blob/master/django_....

In your case, you could probably do this:

    if not hashed_password.startswith("bc$")\
       and sha(entered_password) == hashed_password:
        hashed_password = "bc$" + bcrypt(entered_password)

You don't have the prefix identifier, but that's okay; you just roll out an equivalent now instead, so you only have to check the start of the hash string and do the conversion, if it hasn't already been performed.

Of course, you have to account for the prefix identifier when validating an entered password against the stored hash.

YMMV.

[kmfrk]

On a quick revision, the first code should read

   hashed_password = bcrypt(entered_password)

Not `bcrypt(hashed_password)`.

[technomancy]

We did it on Clojars, the Clojure library source, without much trouble:

https://github.com/ato/clojars-web/compare/68872652fc427cc1....

We had a month or two grace period in which anyone logging in would have their password upgraded to bcrypt automatically, then wiped the SHA1s.

https://groups.google.com/forum/#!msg/clojure/Xg1I0rgt85s/Vf...

[njs12345]

Could you use e.g. bcrypt(SHA1(x))? I think that should be OK, and avoids the issues with switching over current users (just take the bcrypt of the currently stored passwords).

[teyc]

It is always possible to apply additional hashes to the MD5/SHA. First strip away the salt, then apply bcrypt or scrypt, next store both the new salt and the old salt plus the new hash. Validating passwords will require two steps. First, hashing the entered password with old salt, then applying bcrypt one more time.