Hacker News Reader

Comment by themartorana | Hacker News Reader

What's the best way to move a huge database from one scheme to the next? It's hard to keep up...

On your `User` table you have a column such as `hashing_scheme`. If you don't have one of these columns already, create it with the default value of your current scheme (e.g., `bcrypt`)

When a user attempts to log in, you hash the password they submitted with whatever's in that user's `hashing_scheme`. If the password was incorrect, fail early.

If the password was correct, and this user's `hashing_scheme` value is different to the application's `current_hashing_scheme`, you rehash the user's password (that you got via the POST request or otherwise) with the new scheme, update the `password_hash` and `hashing_scheme` value in the database.

This is just one way to do it, which is how Django performs hashing scheme migrations IIRC.

Alternatively, you can update the entire user db at once by hashing their existing password hashes. You'll end up using a double-hash:

    new_hashing_scheme(old_hashing_scheme(password))

Not as elegant, but the benefit is you can immediately move everyone to a new scheme if you need to for some reason.

If you were already using bcrypt (or any "slow hash algorithm"), double-hashing may be very slow.

You only have to do it when you in-place upgrade the entire table, and once when the user initially logs in after that.

Once the user has logged in successfully, you can replace new_hash(old_hash(password)) with simply new_hash(password).

This is less useful for optimistic upgrades like bcrypt->argon2i, but is absolutely critical if you find yourself taking over responsibility for a database that has a password column full of, say, MD5s.

Waiting for each and every user to log in to upgrade those vulnerable hashes is suicidal.

My favorite way would be to store password information as a hash chain, so old users can be immediately upgraded to the latest method while new users just use the latest.

For example, Django currently stores its passwords in a single database column as

  <algorithm>$<iterations>$<salt>$<hash>

So suppose we generalize that to a chain of one or more hash algorithms, with each output fed in as the password to the next, resulting in a final hash:

  <algorithm>$<iterations>$<salt>|<algorithm>$<iterations>$<salt>|$<hash>

For example if you had a user who logged in way back in unsalted md5 days and never logged in again, you might end up with a chain like this:

  md5|sha256$<salt>|bcrypt$<iterations>$<salt>|$<hash>

... and then to upgrade to argon you would grab that string, shove the final hash through argon(), and write back:

  md5|sha256$<salt>|bcrypt$<iterations>$<salt>|argon$<iterations>$<salt>|$<hash>

For new users, or if the old user finally came back and logged in with their correct password, you could then take the opportunity to write back a simplified version:

  argon$<iterations>$<salt>|$<hash>

Iterations could be calibrated differently depending on the chain, if the earlier steps take enough time to matter.

As far as I can tell this is the best possible service you can offer to the users whose long-ago passwords you're storing, short of deleting their passwords entirely. Throwing away the earlier version and replacing it with the argon-wrapped version can't hurt them, and will almost certainly help.

(Usual caveats apply about not doing things that add complexity if you don't need it.)

That's also how PHP handles it for its password_needs_rehash function:

http://php.net/manual/en/function.password-needs-rehash.php (PHP >= 5.5)

> hrowing away the earlier version and replacing it with the argon-wrapped version can't hurt them

Are you sure? And if so, can you convince me as to why you are so sure?

To be specific about my claim: throwing away the earlier version and replacing it with the argon-wrapped version cannot make the user's original password easier to recover, because it adds no new information about the password. To convince yourself of that, imagine that there was some function `argon(hash)` that made the password easier to recover. Why wouldn't an attacker run that function themselves? In the very worst case a bad hash function that takes one second to run could only speed up the attacker's job by one second.

Wrapped hashes could have other side effects for probing non-hacked sites -- for example, attackers could probably figure out which chain a user has based on timing, which would let them narrow down a bit when the user last logged in. Hash chains could also theoretically reduce the total output space for the final hash, making it easier to brute force a password through the login form of a non-hacked site. I don't consider either of those likely to matter, but you might.

Consider something like https://pythonhosted.org/passlib/modular_crypt_format.html and support all your old hash-functions. If you really want to migrate people to the new hash functions, you can:

* Fully expire the accounts (and send emails asking them to reset their password)

* If they successfully login to their account and you have the plain text password, you can re-hash that using argon2i.

* Have them reset their password on next sign in before allowing them to do anything.

* Let the user know their account has less security than it could, and they can upgrade the security by changing their password.

Afaik, there is nothing you can do to upgrade their passwords, modulo argon2'ing the result of another hash function - I am simply too unclear on the safety of this approach so I don't do it.

I've always wondered if there's a security issue by applying the newer hashing algorithm to the old hashes.

I.e. store the result of `argon(bcrypt(md5(password)))`

Any security drawbacks to this?

Here's a discussion on that[0]. Depending on how you do it you either weaken it to the strength of the weakest algorithm or alternatively gain nothing but may introduce a weakness. It's basically a bad idea.

https://security.stackexchange.com/questions/93730/why-not-m... [0]

The arguments in that Q&A look suspect to me - they don't seem to be explicit in what a hash needs to defend against, and as a result, any downside is an argument to avoid a strategy, even if that downside is much less relevant than some other upside.

The top voted answer has a comment that's spot on:

I would offer the opposite argument: if one uses a single hashing function which has a 0.1% chance of having a discoverable weakness that would allow an attacker to speed it up by a factor of a million, there will be a one-in-a-thousand chance that an attacker will be able to gain a million-fold speedup. If one used three independent functions, each of which had a 0.1% chance of allowing such a breakthrough, there would be a 0.3% chance of an attacker being able to achieve a 33% speedup, a 0.0003% chance of an attacker getting a 66% speedup, and only a 0.0000001% chance of an attacker... – supercat Jul 13 '15 at 17:21

...getting a million-fold speedup. I would consider the possibility of an attacker getting a 33% speedup as inconsequential compared to the reduction in the probability of the attacker getting a 70%-or-better speedup. – supercat Jul 13 '15 at 17:22

In short: You lose on average (but who care?) but you reduce the risk of catastrophic failure.

Reply on news.ycombinator.com