We help IT Professionals succeed at work.

Storing users password history securely with salt

Lee Redhead
Lee Redhead used Ask the Experts™
on
Hello,

I am just working on the login for a site that I am currently updating and have an issue with how to handle users passwords history.

The issue I have is that I need to store the history of passwords for the user for the last 10 passwords (dictated by client) and they need to expire every 30 days.

At the moment I have the first part sorted with the passwords for each user hashed and salted with the data table having both the hashed and salted password. The problem I have is now storing the password history. I can think of two ways to do this but I am not sure which is best.

Firstly, it is reuse the users salt each time they use the password then store the salted hash of the password in a history table that is linked to the users ID so when they change their password it checks to see if the password has been used before, deleting all but the last 10 passwords in this table for that user each time the proc is run.

Secondly, change the salt each time, but this would mean bringing back the last 10 passwords and their salt then salting and hashing the new password 10 times and checking it against the table to see if the salted hash matches any existing records.

I am leaning towards the first option as I suspect if somebody has gained access to the server then the least of my worries is having the same salt used each time for a user (of course each user will still have a different salt so if somebody was to crack one password they would still have to go through each user separately) but of they have gotten that far then they could rewrite the login scripts and negate security anyway.

Is that method acceptable from a security point to use the same hash for a user each time they change their password? Obviously their will be the standard warning about not using the same password as for other systems, etc.

Thank you in advance,

Lee
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Most Valuable Expert 2017
Distinguished Expert 2018
Commented:
Why change the salt each time? If you are going to have to store the historic salt information in order to validate the password - just keep the salt the same.

Store the hashed / salted password in hitory table and each new password salt + hash and then check to see if in history - if it is - fail.

I would keep it very simple to begin with - get your signup and history checking cycle working with 30 day timeout and checking last 10 - once that is stable you can consider amending if necessary.

I just re-read your post and there may be an ambiguity there.

Are you asking if you should use 1 salt for all passwords or per user - or are you asking if you should have a different salt per user and then change it each time they change their password?

To clarify my position - in your user table you have a field for password (hashed) and salt and date_set.
Each user account has its own unique salt but remains constant across password changes.

History table only stores past 10 passwords hashed and salted.

New password is hashed and salted (using salt from user record), checked against values in history for that user and if that passes user account is updated with new password and password that was there is written to history and 11th entry (if it exists ) is removed
Lee RedheadManaging Director

Author

Commented:
Thank you for the reply, that has helped confirm what I thought was the best way to handle the history.

To confirm, each user has their own salt which is created at the time of account creation. As suggested this will be kept for the user on each password change. The for the history the salted hash password will be stored so that this can be checked against the new passwords salted hash and if it exists in the table (after the 11th records has been deleted) then the users is instructed to try a new password.

The user table has salted hashed password (do not store the hash on its own), salt which is returned on login to salt and then hash the input to compare against the existing salted hash from the user record and date of last password change. It also has a control code which is used for determining the status of a users account and if the password needs resetting (for example if the user forgets password and we issue a temporary password).

Thank you once again.

Lee
Most Valuable Expert 2017
Distinguished Expert 2018

Commented:
Yup that about sums it up.

You are welcome.
I'm reading that keeping the salt the same really is the same as no salt at all.  I thought the purpose of the salt was to add a random section of password to the entered password.  Keeping it the same, is the same as adding 5678 to the end of the password each time.