5 ms·

To be 'fair': when Last.fm first launched, md5 was probably 'state of the art'. I mean take a step back, they have been around for like forever. The question i

To be 'fair': when Last.fm first launched, md5 was probably 'state of the art'. I mean take a step back, they have been around for like forever. The question is: How would you go on about moving your user database from md5 to a more advanced algorithm? Validate a user's password on log-in and then encrypt it with the new, more secure algorithm?

cschmidt 14y ago
Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else: _______ Password upgrading When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented. https://docs.djangoproject.com/en/dev/topics/auth/#password-upgrading https://docs.djangoproject.com/en/dev/topics/auth/#password-... _________ So it would be trivial for the big sites to have switched transparently to a safer hash, even if MD5 was Ok when they started. You could also add salts in the same way, if you were storing unsalted hashes.
- raverbashing 14y ago
  Kudos to Django because this is very important Like in bcrypt discussion saying you can tune the amount of work. Sure, but what to do with the existing hashes! Of course, the user needs to retype their keys, but it's better than keeping old credentials. (or maybe you save the original credentials with strong PK crypto, together with the hash, then periodically decrypt offline and rehash)
  - powersurge360 14y ago
    In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.
  - powersurge360 14y ago
    In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.
- pek 14y ago
  Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until the users log in.
  - EvilTerran 14y ago
    As hashing functions aren't injective, composing them leads to a reduction of range (ie, a smaller set of possible output values). As such, (bcrypt . MD5) would almost certainly be a weaker hash than bcrypt alone. Might not be enough to make a difference, but I'd consult a cryptologist before betting on that.
    - pek 14y ago
      Yeah, it would be weaker against a collision attack. But that shouldn't be a concern as the purpose of the password hashing function is to protect against a preimage attack: finding the password given its hash. I can't see how the composition could be more vulnerable to a preimage attack than its parts. (Provided that the inner function's output is evenly distributed.)
  - dsingleton 14y ago
    They have some older APIs that depend on MD5(password) being used directly, to compare against auth credentials or to derive other hashes to verify API requests. Though older APIs they're still used by many older or infrequently updated clients, such as hardware devices with sold with Last.fm integration. Unfortunately, the longer you've been around the more likely you are to develop dependencies that make it more difficult to upgrade your password hashing. A new site can do whatever it wants with password hashing, but it becomes harder for older sites with more legacy dependencies to make that kind of change and Last.fm has been around for almost 10 years. This isn't to say "MD5 is cool, don't worry", but to try and illustrate some of the reasons behind this.
- soulclap 14y ago
  Great feature. So you alter the password field (extending the length) if needed and when a user signs in it gets auto-updated and Django always tests both/all specified algorithms? Or do you have to add a new database field when moving on? (Sorry for my tl;dr behaviour but while I've got an expert on the line anyway...)
  - cschmidt 14y ago
    I'm not an expert in any sense, just a Django user. I've never actually looked under the hood, since it just works. You specify an order of the hash algorithms, putting the one you want first. Switching to bcrypt for me was just a matter of moving it up a few lines in a list. The password field can probably stay the same length, since it is a hash value anyway. I'm assuming you have a second field that stores the hash algorithm used. When it logs you in, it uses the current algorithm to authenticate you. Then if that technique isn't first on your list, it creates a new, salted hash, and stores both that and the new hash type in the database. Nice and slick.
    - soulclap 14y ago
      thanks for the insight, much appreciated. never really thought about how to do this before. (screams for a 'website security patterns' book.)
notlostyet 14y ago
You can also just hash the existing hashes. bcrypt(salt + old_md5). New passwords can use a new MD5-less scheme.
mikeash 14y ago
I don't believe straight unsalted MD5 was ever state of the art for password hashing. Yes, it was a state of the art cryptographic hash at one point, but those are not the same thing.
jedbrown 14y ago
Unsalted was not "state of the art" in the 1970s. The database would be far more secure if it had used a weaker hash with salt. To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.
- soulclap 14y ago
  You are right, I just meant to say that the 'awareness' has increased a lot since Last.fm first stepped on the scene. Unless you were already security-savvy and had a hacker (as in the original sense of the word) background, I guess no one really cared back then. On a sidenote, I just changed passwords for what was probably my second last.fm account and I haven't logged in or 'scrobbled' since 2007. Different times for sure.
  - jedbrown 14y ago
    You talk as though 2003 was prehistoric.

cschmidt 14y ago

Yes, that's exactly what you do. In Django 1.4 (the latest), they store passwords using PDKDF2 or bcrypt. The nice thing is that it automatically upgrades the hash function if it used to be something else: _______ Password upgrading When users log in, if their passwords are stored with anything other than the preferred algorithm, Django will automatically upgrade the algorithm to the preferred one. This means that old installs of Django will get automatically more secure as users log in, and it also means that you can switch to new (and better) storage algorithms as they get invented. https://docs.djangoproject.com/en/dev/topics/auth/#password-upgrading https://docs.djangoproject.com/en/dev/topics/auth/#password-... _________ So it would be trivial for the big sites to have switched transparently to a safer hash, even if MD5 was Ok when they started. You could also add salts in the same way, if you were storing unsalted hashes.

raverbashing 14y ago
Kudos to Django because this is very important Like in bcrypt discussion saying you can tune the amount of work. Sure, but what to do with the existing hashes! Of course, the user needs to retype their keys, but it's better than keeping old credentials. (or maybe you save the original credentials with strong PK crypto, together with the hash, then periodically decrypt offline and rehash)
- powersurge360 14y ago
  In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.
- powersurge360 14y ago
  In regards to "what to do with the existing hashes" bcrypt can detect the original work factor and hash to that. Not sure how you would upgrade that for users, however.
pek 14y ago
Couldn't you just move from, say, using MD5(password) to bcrypt(MD5(password))? So when it becomes apparent that the old hash is no more secure, start using the combination of the old bad hash (MD5) and the new good hash (bcrypt). This way you can simply run once through the password database, hash each password hash there with the new better hash, and throw away the old hashes. No need to prolong the process until the users log in.
- EvilTerran 14y ago
  As hashing functions aren't injective, composing them leads to a reduction of range (ie, a smaller set of possible output values). As such, (bcrypt . MD5) would almost certainly be a weaker hash than bcrypt alone. Might not be enough to make a difference, but I'd consult a cryptologist before betting on that.
  - pek 14y ago
    Yeah, it would be weaker against a collision attack. But that shouldn't be a concern as the purpose of the password hashing function is to protect against a preimage attack: finding the password given its hash. I can't see how the composition could be more vulnerable to a preimage attack than its parts. (Provided that the inner function's output is evenly distributed.)
- dsingleton 14y ago
  They have some older APIs that depend on MD5(password) being used directly, to compare against auth credentials or to derive other hashes to verify API requests. Though older APIs they're still used by many older or infrequently updated clients, such as hardware devices with sold with Last.fm integration. Unfortunately, the longer you've been around the more likely you are to develop dependencies that make it more difficult to upgrade your password hashing. A new site can do whatever it wants with password hashing, but it becomes harder for older sites with more legacy dependencies to make that kind of change and Last.fm has been around for almost 10 years. This isn't to say "MD5 is cool, don't worry", but to try and illustrate some of the reasons behind this.
soulclap 14y ago
Great feature. So you alter the password field (extending the length) if needed and when a user signs in it gets auto-updated and Django always tests both/all specified algorithms? Or do you have to add a new database field when moving on? (Sorry for my tl;dr behaviour but while I've got an expert on the line anyway...)
- cschmidt 14y ago
  I'm not an expert in any sense, just a Django user. I've never actually looked under the hood, since it just works. You specify an order of the hash algorithms, putting the one you want first. Switching to bcrypt for me was just a matter of moving it up a few lines in a list. The password field can probably stay the same length, since it is a hash value anyway. I'm assuming you have a second field that stores the hash algorithm used. When it logs you in, it uses the current algorithm to authenticate you. Then if that technique isn't first on your list, it creates a new, salted hash, and stores both that and the new hash type in the database. Nice and slick.
  - soulclap 14y ago
    thanks for the insight, much appreciated. never really thought about how to do this before. (screams for a 'website security patterns' book.)

notlostyet 14y ago

You can also just hash the existing hashes. bcrypt(salt + old_md5). New passwords can use a new MD5-less scheme.

mikeash 14y ago

I don't believe straight unsalted MD5 was ever state of the art for password hashing. Yes, it was a state of the art cryptographic hash at one point, but those are not the same thing.

jedbrown 14y ago

Unsalted was not "state of the art" in the 1970s. The database would be far more secure if it had used a weaker hash with salt. To migrate, Unix-like systems generally support database migration through a modular format (see "man pam_unix" and /etc/pam.d/passwd). The next time the password is changed, the field that looks like $1$<salt>$<md5hashedpasswd> will be converted to $6$<salt>$<sha512hashedpasswd>. I guess you could change it at the next login if you allowed modification to the password table during login. If you were eager, you could just salt and rehash the hashes current hashes. To check that password, you would do the old unsalted md5, then apply the salt and sha512 (or whatever) before checking in the database.

soulclap 14y ago
You are right, I just meant to say that the 'awareness' has increased a lot since Last.fm first stepped on the scene. Unless you were already security-savvy and had a hacker (as in the original sense of the word) background, I guess no one really cared back then. On a sidenote, I just changed passwords for what was probably my second last.fm account and I haven't logged in or 'scrobbled' since 2007. Different times for sure.
- jedbrown 14y ago
  You talk as though 2003 was prehistoric.