I am mantaining a legacy software that uses MD5 in the following way:
- The client asks for a 16 byte salt when authenticating an account.
- The server generates a 16 byte salt, links it to the account and sends it back to the client.
- The client appends the 16 byte salt on a password, does MD5(pass + salt) and sends the MD5 hash through the network.
- As the server stores the plaintext password in the database, it only retrieves the password and compares MD5(database_pass + salt) with the received MD5(pass + salt) from the client.
As I can't change the workings of the client, I was thinking about what I could do to stop storing the plaintext password on the database. The idea I came with was to, instead of storing the plaintext password on the database, to store the 16 byte salt used by the client and, at the registration, generate the MD5(pass + salt) and use this MD5 as the input to PBKDF2 with a 64 bytes salt and HMAC-SHA512, 10000 iterations. Then, to authenticate, I would receive the MD5(pass + salt) from the client and PBKDF2 it to check with the stored PBKDF2 hash.
My doubt is, will this make my server more secure? As the password and the MD5(pass + salt) won't be stored on the database, the password won't be accessible anymore if my database leaks, but is there a problem with using MD5 before?
Are there any possible problems with this approach? Is there a better approach to it?
The only drawback I can think of is that I won't have access to the client's password after a successful authentication, so changing the authentication system later will be difficult. I will have the MD5(pass + salt), but then changing the salt would be impossible.
I want to do this right because I won't be able to change the system later. Any help is appreciated.