0

Ok- so you all probably know that a hash is used to help secure a stored password in a database, if it was stolen.

When a user logs in, and enters a password, it gets hashed, and then matched to a hash in the name of the user that tried to log in (that is stored in a database,) and if they match, the user is ‘allowed’ in. Right?

So what I am wondering is what if said application, let’s call them ‘company-A,’ wanted to change their hashing algorithm from MD5 to the more secure SHA-1, how would they do this?

Because they don’t actually know (or store, more accurately,) your password, they just know your hash, so they couldn’t just re hash your plain text password.

I’m not saying this situation would happen all the time, but it would happen often enough.

These are my thoughts/ideas on how a company or application might approach it:

  1. They brute force every hash to obtain the original password and then convert that to their new hash algorithm.

Just typing that made me feel stupid! Obviously this is not how said company would go about it- this approach would be ridiculously resource and time consuming!

  1. This is the most feasible approach I can think of, but it still has some flaws.

Once they decide they want to change their hash algorithm, Company-A waits until a specific user logs in, and enters their password, ‘P@ssword1’. The hash of P@ssword1 matched the hash in Company-A’s database, so they know it is valid, and then P@ssword1 gets hashed again, but hashed into the new SHA-1 hash, and now the new SHA-1 hash replaces the old MD5 hash in Company-A’s database.

Is this theory right? Am I close or far off?

I am interested in knowing this because I feel that this must happen often enough that it could be an issue that companies and databases suffer from.

Please also let me know if this question does not belong in Information Security SE as well!

2

2 Answers 2

4

The application does not have to and should not wait until the user has logged in. They can hash all currently stored hashes with the new algorithm to produce h2(h1(p)), where h1 is the old algorithm and h2 the new one (salts and other parameters omitted). When the user logs in with a password p', the application calculates h2(h1(p')) and compares it with the stored hash. If they match, it's possible to replace h2(h1(p)) with h2(p') to get rid of h1.

This avoids the situation where less active users still have the old hashes for an indefinite amount of time. Depending on how weak the current algorithm is, it can also be advisable to delete all hashes (possibly after a grace period) and force the users to reset their passwords.

1
  • “ This avoids the situation where less active users still have the old hashes for an indefinite amount of time.” Yes… I was wondering this- thanks very much for answering my question! Commented May 6 at 1:08
3

You answered your own question - your second hypotheses is correct, this is how it's done in practice.

Notice that the password hashing function built-in to most frameworks is actually designed with the need for this eventual migration in mind. For example, see the documentation for PHP's password_hash() function. The page shows an example of the output of the function, like so:

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

The $ is used as a delimiter. The first value (in this case, '2y') specifies the hashing algorithm used. This way, the system can keep track of which hashing algorithm is used for a particular user, as users are migrated to newer algorithms.

1
  • thanks- I thought my hypothesis was right! That makes sense though- they track user hash types for when transitions are made! Thanks! Commented May 6 at 0:52

Not the answer you're looking for? Browse other questions tagged .