views:

1039

answers:

7

I've got an old application that has user passwords stored in the database with an MD5 hash. I'd like to replace this with something in the SHA-2 family.

I've thought of two possible ways to accomplish this, but both seem rather clunky.

1) Add a boolean "flag" field. The first time the user authenticates after this, replace the MD5 password hash with the SHA password hash, and set the flag. I can then check the flag to see whether the password hash has been converted.

2) Add a second password field to store the SHA hash. The first time the user authenticates after this, hash the password with SHA and store it in the new field (probably delete their MD5 hash at the same time). Then I can check whether the SHA field has a value; this essentially becomes my flag.

In either case, the MD5 authentication would have to remain in place for some time for any users who log in infrequently. And any users who are no longer active will never be switched to SHA.

Is there a better way to do this?

+2  A: 

I think you've already got the best possibilities. I like #1 more than #2, since there's no use for the md5 once the sha is set.

There's no way to reverse the MD5, so you have to wait for the user to authenticate again to create a new hash.

Ned Batchelder
A: 

Your second suggestion sounds the best to me. That way frequent users will have a more secure experience in the future.

The first effectively "quirks-mode"'s your codebase and only makes sure that new users have the better SHA experience.

Jeff Wilcox
To me it seems the two solutions are the same, only implemented slightly differently. In either way, your password is rehashed on your next login.
Jørn Schou-Rode
In either option, I would replace the passwords of existing users the next time they log in. It's just a question of how to let the app know which hash to use after that.
Bruce Alderman
+1  A: 

No - basically you'll have to keep the MD5 in place until all the users you care about have been converted. That's just the nature of hashing - you don't have enough information to perform the conversion again.

Another option in-keeping with the others would be to make the password field effectively self-describing, e.g.

MD5:(md5 hash)
SHA:(sha hash)

You could then easily detect which algorithm to use for comparison, and avoid having two fields. Again, you'd overwrite the MD5 with SHA as you went along.

You'd want to do an initial update to make all current passwords declare themselves as MD5.

Jon Skeet
The size of the hash makes it self-describing: MD5 is always smaller.
Steven Sudit
Length shouldn't be used as the sole indicator. You might want to change what goes in the hash (e.g. nonce calculations, other seed data) while using the same hash algorithm to chop it all up. Having a separate identifier indicates to you which of *your* password hashing schemes is in use.
Rob
If your only two methods differ in length then you certainly can use length as an indicator.
Vinko Vrsalovic
Rob, I agree that having an extra byte or so up front as an indicator is a good idea. Conveniently, the legacy MD5 values will be shorter than even an MD5 with that extra byte.
Steven Sudit
A: 

If the MD5's aren't salted you can always use a decryption site/rainbow tables such as: http://passcracking.com/index.php to get the passwords. Probably easier to just use the re-encode method though.

Meep3D
If feasible this is not very ethical, unless you take a lot of care not to store any password while you are cracking them.
Vinko Vrsalovic
@Vinko - for some reason it feels unethical even if you take care to prevent the password from being stored/leaked.
Michael Burr
+4  A: 

Essentially the same, but maybe more elegant than adding extra fields: In the default authentication framwork in Django, the password hashes are stored as strings constructed like this:

hashtype$salt$hash

Hashtype is either sha1 or md5, salt is a random string used to salt the raw password and at last comes the hash itself. Example value:

sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
Jørn Schou-Rode
This is the best answer.
Steven Sudit
The only issue with this is that it stores the salt in such a way that makes it obviously the salt, rather than using another unique or derived value for the user (such as a mutated version of the timestamp of their account creation, or bit-flipping their username, etc). It's arguable whether this makes any currently feasible difference in how long it would take to crack, I'm just paranoid.
Dustin Fineout
@Dustin: the extra strength here is the salt can be changed every time the user changes his password.
Joshua
But you're storing the salt. If I have your DB and all your hashes, I have your salts too.
Dustin Fineout
@Dustin: In this setup, the salt is merely there to render attacks using [rainbow tables](http://en.wikipedia.org/wiki/Rainbow_table) useless, as the salt will be different for each user.
Jørn Schou-Rode
Yes I understand the benefit, I was merely stating I personally prefer not to store the salt so that it is obviously the salt. As I said before knowing the salt doesn't necessarily make it any more feasible to crack the password, but I'm paranoid. I use a salt that's different for every user, but it's derived from another value unique to the user. Even if you have my whole DB you won't know where the salts are coming from unless you also have the application code. Probably not a practical increase in security because salting alone is enough (currently), but it IS more secure to hide the salt.
Dustin Fineout
Good security rests on the assumption that any potential attacker knows your methods. That's why we use "crytographically secure" hashed, not "cryptographically obscure" hashes. As Jørn points out, the only (quote "merely") added security of a hash is to defeat rainbow tables and such. They are a complement to cryptographically secure hash functions.
maxwellb
+1  A: 

You can convert all your MD5 Strings to SHA1 by rehashing them in your DB if you create your future passwords by first MD5ing them. Checking the passwords requires MD5ing them first also, but i dont think thats a big hit.

php-code (login):

prev: $login = (md5($password) == $storedMd5PasswordHash);

after: $login = (sha1(md5($password)) == $storedSha1PasswordHash);

Works also with salting, got the initial idea from here.

wolph
A: 

Yes you should know the real password first before you convert it into sha-1..

If you want to find the real password from md5 encrypted string, you can try md5pass.com

liputra
This should never be possible in a well designed system. All passwords should be stored salted.
William T Wild