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?
_______
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-...
_________
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.
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)
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.
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.
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.
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.