Link to home
Start Free TrialLog in
Avatar of Lee Redhead
Lee RedheadFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Storing users password history securely with salt

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
ASKER CERTIFIED SOLUTION
Avatar of Julian Hansen
Julian Hansen
Flag of South Africa image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Lee Redhead

ASKER

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
Yup that about sums it up.

You are welcome.
Avatar of atljarman
atljarman

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.