How to design system to allow migration of encryption?

Question

I want to set up a system where I am allow to migrate encrypted password (hash password), from one system to another. How would i do this?

Say 2 month down the line, i found a encryption that is 10 times better and the current hash function has been proven without a doubt, totally vulnerable. How would I go about migrating user password from one type of hash to another (the better one).

Answer 1

You can slowly migrate from a method to another using the following technique. I cannot guarantee its quality so please take it with a grain of salt (pun not intended).

For example, consider the following table, that stores users:

id    name    password    salt    hashmethod
--------------------------------------------
1     alice   ABC52...    ABD...  md5
2     bob     28DHF...    Z+d...  sha1
...

Say that your outdated hash method is md5 and you want to replace it with the more secure sha1, this is what you do:

• A user logs in, you hash its password with the new method (sha1) and salt.
  • a) If a match is found (corresponding username and password and method sha1), the user is logged.
  • b) If a match is not found:
    • 1) You hash with the old method (md5) and salt.
      • a) If a match is found (corresponding username and password and method md5), you hash the password with the new method (sha1) and salt, and update the database accordingly. The user is logged.
      • b) If a match is not found, the credentials are invalid and the user is not logged.

This migration can take a long time, so to speed it up you should e-mail your users asking them to log in or change their passwords.

Hope it helps.

Answer 2

In general, you can't. You can't recover the passwords from the hashes; that's the entire point of a hash. If the original hash function was so broken that you can recover the passwords, then you might as well just do that and then hash them with the new function.

Answer 3

Generally, the way you do this is as follows:

1) You generate a public/private keypair, usually using RSA.

2) You secure the private key thoroughly. You never, ever store it online. (You may want to split it in halves and trust those to different people. You may want to use secure secret sharing. You may want to secure it in a token.)

3) Any time you store a password, you also store a copy encrypted with the public key you generated.

4) If, in the future, recovery of plaintext passwords becomes necessary, you recover the private key and decrypt the stored copies of the passwords.

Note that this is the technical description of how you do it. How you do is securely is complicated and depends on your exact situation. For example, you have to consider threat models where an attacker replaces your public key with his own.

Answer 4

This only apply to systems that uses one-way hashing method to store passwords, and compares hashes at authentication.

If there is a frequent such upgrade required of your system, I would do the following.

As Taymon has pointed out, hashing is one way and there is no way you can retrieve the original plain text from the hash.

In my database table storing the user information and password, I would include a Hashing Level integer field. This indicates which hashing method the user is using.

When the system is added with a new hashing method, the highest Hashing Level will be incremented.

Let's say if I have 2 hashing methods already

1    MD5
2    SHA1
3    SHA256

If I add in a new hashing method SHA512, it'd become

4    SHA512

Every time the user signs in, the system will check if the user's password is the same as the one in the database, using the identified Hashing Level. There are several cases here:

• If the password hashes match, but the Hashing Level of the user is not the highest Hashing Level the system offers, then hash the input password of the user i.e. the plain text using the highest level of hashing method and set the Hashing Level of the User to the highest Hashing Level. The user is then authenticated.
• If the password hashes match and the Hashing Level of the user is the highest Hashing Level, then the user is authenticated.
• If the password hashes do not match at all, then the user is denied.

This means that whenever you upgrade the hashing level of the system, the user's password is only upgraded to the highest level at their next authentication.