Is there a way to add salted hashing to my user authentication without breaking my former login server

Question

I am presented with the following scenario:

I have a MySQL-Database with a table of users. The table has two fields: username and password. The password is stored as an unsalted hash.

An over 15 year old application uses this database to authenticate access to its services. It is only accessible internally.

Our team is tasked to modernize these services by offering a new application following best practices and lessons learned of the last 15 years (and potentially more that were ignored in the original application). This application shall be accessible from the wide open internet.

We are supposed to reuse the current database for authentication purposes to allow both applications to run in parallel on the underlying same authentication database.

I voiced several concerns regarding security as this application is about handling personal details of my coworkers and me.

We decided that part of our modernization is that password policies are put in place and that passwords are stored both salted and peppered.

This means our database table would get a third field salt and the password field now stores our salted and peppered hash.

The problem here is that this will break the authentication in our old application. As the code is very much legacy and we don't even have a working compiler for it anymore changing the code of the original application is out of question.

My question therefore is:

• Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users? Keep in mind that while the old application is inherently insecure it will not be accessible outside of our intranet, the new application however will be.

Answer 1

You have conflicting requirements here. The compatibility requirements forces you to keep the old hashes. The security requirements forces you to drop them. You will have to make a choice here about what requirements to fulfill.

If you decide to keep the backwards compatibility, try making the best out of a bad situation:

• The old hash and the new hash should be stored in different tables, and the database user that the web application uses should not have read access to the old hash. Use table and/or column permissions for this.
• As soon as you no longer need the old application, drop the table with the old hash. Ashley Madison famously failed at this point - they upgraded to bcrypt, and then for some idiotic reason they left the old MD5 hashes lying around in the database. When the database was leaked, that fancy bcrypt did not help much...

Or, alternatively, if you are not afraid to create a bit of a mess:

• Drop the old hashes. In the new application, add on option "Create temporary password for old application". It gives you a long, random password that is hashed in the old way and only kept in the database for X minutes. The user can then logg in to the old application, and the password is then automatically deleted.

Answer 2

Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users?

Yes, this can be done. Below are high-level implementation instructions. The basic technique is to hash all the passwords, then MITM the connection between the client and the legacy server in order to replace the unhashed password with a hashed password. Note that you'll need to come up with a roll-out plan; blindly running step 1 in production will break everything.

Step 1: Salt all existing passwords, then store the salt somewhere. Overwrite the password field of the legacy database with the salted password.

Step 2: Create a shim. The shim will accept identical parameters as the legacy APIs.
So, if the Legacy API is implemented as:

LegacyDoStuff(username,password,argument)
{
    if(!VerifyCredentials(username,password)) return AuthenticationError();
    result = DoStuff(argument);
    return result;
}

The new API is implemented as:

NewDoStuff(username,password,argument)
{
    hashedpassword = DoHash(password+getSalt(username))
    return LegacyDoStuff(username,hashedpassword,argument);
}

Step 3: Point the legacy client at the shim, instead of the main server (or equivalently, move the legacy server to new IP/DNS, then put the shim at the old IP/DNS).

This approach does allow you to treat the internals of the legacy code as a black box, but it requires you to be aware of the public surface area of the legacy code, since your shim will need to send requests/responses between the client and the legacy server.

This approach, unlike the approaches described in other answers, completely avoids storing the old password. However, this approach is much more difficult to do and is far more likely to introduce bugs.

Answer 3

Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users?

No. The reason for salting and hashing passwords is so that if the user database is hacked/leaked/compromised, the users' passwords are not accessible to the attacker (see What is the point of hashing passwords?). In the solution that you describe, the users' passwords are still stored in the user database, in an adjacent column, in plaintext. This completely defeats the purpose of salting and hashing passwords.

Answer 4

Clearly the current table needs to remain so the old application can work.

Maybe add a new table with salted+peppered hashes for the new application to use, then:

• Make the old table inaccessible to the new application!
• Update both tables when updating a user's password
• Require all users of the new system to update/reset their password
• The new table can store a copy of the old hash initially, then update it to be properly hashed when the user updates their password.

This assumes that the password control system is separate from either of the content systems.

This means that any vulnerability in the new system can't access the old hashes (once migrated). The database could have a vulnerability that allows the new system's database credentials have access to a table it shouldn't, but that's much less likely than your new application having a vulnerability.

Answer 5

1. Add two new columns, a salt column, and a new hash column, initially null.
2. When an authentication request comes in, check the salt field.
3. If the field has a value then there is a new-style hash that has pepper and salt added. Handle accordingly.
4. If not, then this is an old-style hash. Verify using the old mechanism. Assuming it succeeds, you now have the plaintext password from the original request; generate and store a salt and you now have everything needed to compute and store a new-style hash. The legacy system won't know to do any of this, so only the new system can do it. (It would have been better if neither system had to deal with it but could delegate the job to the database itself. The new system can, the old system can't.)

Eventually either everyone has logged in at least once and had their hashes transparently updated (there are no NULL salts left in the table), or the only ones left are those who never log in at all.

Putting the unsalted and salted hashes right next to each other in the table just illustrates the fact that for as long as the legacy system continues to be used, the use of best practices in the new system will continue to be irrelevant from the standpoint of security.

Answer 6

Yes this is possible.

In the new application, have a hash-of-hash double hash algorithm eg:step1 : hash the salted password , step2 : hash that hash (no salt)

Approach #1:

Develop a simple standalone app that takes a password and generates the salted hash of a user password and displays to screen or silently to clipboard.

Ask all internal users to reset their password in the old application to the output of the standalone app, and from now on when logging in use the process of entering the password into the standalone app to generate the password hash that will be entered into the login screen. The output could be generated to clipboard to avoid visual clues.

Approach #2

If you can somehow use the db, do the hash of hash in the database. Make step 2 the salted hash and only store that.

Edit to clarify: example: if using a DB that supports custom operators then declare a custom equality operator on a column storing the newsaltedhash(oldhash) as a custom type. When the app runs a query for row with matching username and oldhash, the custom operator will execute newsaltedhash on the incoming hash and do the comparison. Password reset is handled by insert triggers.

Summary: In both scenarios your apps function as originally designed and the stored password hash is a hash+salt double hash.(Pepper optionally added in either implementation)

Answer 7

This answer is inspired by Brian's answer and Frank's Approach #1 which both essentially use the new salted hash as the password for the old application. Since that requires an application to retrieve the salt from the database to generate the hash, it would be simpler and more secure to have that application authenticate the user, and use a completely separate random token as the password for the old system.

Step 1: Choose a modern password hashing solution

Pick a well-supported password hashing library for your language of choice, which should handle generating secure salt for you. It will probably output a single string containing the hash, salt, and other parameters needed to verify the password, allowing you to gradually roll out a stronger algorithm in future. For instance, in the case of PHP, use the built-in password hashing functions.

Create a new column in the database to store this single string. One way to populate this initially is to calculate NewHashFunction(OldStoredHash), and then run NewVerifyFunction(NewStoredHash, OldHashFunction(UserEnteredPassword)). There are plenty of existing discussions of this, and it doesn't make a difference to the rest of this answer.

Step 2: Blank the old password column

Permanently wipe all the old insecure hashes, but don't drop the column. At this point, nobody can log into the old application, so we need to fix that...

Step 3: Build a tool to log into the old application

Build a page in your new application (where the user is already authenticated) or a standalone page (which authenticates the user using the new password library) which does the following:

• Generates a long random password
• Stores the unsalted hash of this random password into the old password column for the authenticated user
• Either displays the password to the user to enter into the old application, or directly submits it to log the user in automatically

Note that this random password doesn't need to be stored anywhere, because if the user wants to log in again, they can simply generate a new one.

Step 4: Make it more secure by timing out the tokens

The random passwords are bound to be much stronger than most users would have set unless using a password manager, but they will still be stored unsalted, and probably using a fast hash. There is also a risk that the password will be copied somewhere when shown to the user. We can make both attacks much harder by only having the random passwords valid for a short period of time.

Add an extra column to the DB for "random password expiry date". This can be extremely short if logging in automatically, and a few minutes if the user has to enter the password themselves. A scheduled job should then run once a minute, and blank the old password field for all rows which have expired.

Answer 8

As pat of the upgrade, add a column to the user table indicating whether or not the account has been upgraded. If it hasn't then use the old code to generate and check the hash. If that's OK then generate the salt and the new hash and update the user record to the new hash, salt, and set the Upgraded flag.

If the Upgraded flag is set on login, the use the new code to read the salt, make the hash and check that.

Answer 9

Storing salted passwords is soooooooo 1995. Therefore you should (if nothing better is possible) at least store a salted hash with many iterations of the hash. This is actually less troublesome than you think.

One concern about this scheme is that you don't know how many iterations are enough, and as computers get faster, you will eventually need more. Over-hashing too much is very expensive, though... especially for a large user database. How to solve this?

The commonly applied solution to that question is at the same time the solution to your primary problem.

In order to account for growing CPU (or GPU, really) power, you add another column with the number of iterations. Every now and then, you add one iteration to a user (for example, 5% random chance at every login). This is very little work because you only need to do one extra hash. Update both the count, and the stored hash.

Now, one needs to realize that a hashed password is still only a password. It's kinda "unreadable", but it is still only a password, nothing else. Nobody prevents you from salting that and hashing it again. Even hash it many times. No harm done.

So, whenever your authentication layer pulls a row from the database where the hash count is zero, it knows that this is an "old" entry where the password has not been salted (it has zero extra hash rounds). So... salt it, hash it a thousand times, and store 1000 for the hash count as well as the salted hash. Done.

The login procedure would thus be something like (in pseudocode):

hash_entered = H(password_entered);

[hash, count] = sql_query(SELECT WHERE username=blah);

if(count == 0)
{
    login_success = compare(hash_entered, hash);
    for(i = 0; i < 1000; ++i) hash = H(hash);
    sql_query(UPDATE hash = hash, count = 1000);
    return login_success;
}
else
{
    for(i = 0; i < count; ++i) hash_entered = H(hash_entered);
    login_success = compare(hash_entered, hash);

    if(random(100) <= 5)
    {
        hash = H(hash);
        sql_query(UPDATE hash = hash, count = count + 1);
    }
    return login_success;
}