Adding unique salt to already hashed passwords in mysql

Question

I am trying to add unique salt to the hashed passwords in MySQL database. What is the most legitimate way of doing this? I am aware of that I need to hash them again to add a salt. These passwords are used for the website login. I can add one particular salt to each password before the code (written in C#) sends the user info to the database. In such a case, the login will work if I salt the passwords in MYSQL with the same salt. I know that it is not the most secure way. How do I implement the same with unique salts for each?

Answer 1

As the comments above state, you cannot reverse a hash, so you can't get the original password back to apply salt. You could apply salt to the hash string and hash again, but then you'd be stuck with that weird double-hash authentication method forever. Be sure to comment your code to explain why it is implemented this way, because programmers who take over your code when you leave will be confused.

I'll tell you how I did it when I was working on an app that needed to update its password-storage code from using MD5() to using salt + SHA1().

1. Leave the old hashed passwords alone.

2. Add a new column to the table storing your passwords for the new format of password. Call it password2 or something like that. This column is NULL by default.

3. Change the code to check the new column. If it is not NULL, then authenticate the user's input using the new hash method against what is stored in the database.

4. If the new column is NULL, then check against the old password using the old authentication method. Ie hash the user's input and check that hash against what is stored in the database. Once you know the input is correct, hash the input again using the new method (add salt and hash the input, or better yet, use Bcrypt or Argon2 which contains its own salt in the hash result) and store that result in the new column.

5. Also set the old column to NULL after the new hash format is stored in the new column.

6. Of course the password-change code and new account creation code will also need to be changed. It should ignore the old password column, leaving it NULL, and only store passwords in the new format in the new column.

7. Once all users have logged in at least once, the old password column should be NULL on all rows. You can remove the application code that supported the old password hash format, and then drop the old password column.

   But there will almost surely be some stragglers who don't log in regularly, so after a few weeks of waiting, I would just proceed to drop the old password. Those users who haven't logged in recently will be forced to do a password reset.

The advantage to this method is that it works totally seamlessly for nearly all your users, and inconveniences only a few (and some of those users may never return anyway).

The disadvantage is that it takes a few weeks to wait for everyone to log in once. If you need the change to occur immediately, then you may have to force all the users to do password reset.