Storing users password history securely with salt

Posted on 2012-08-28
Last Modified: 2014-11-10

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,

Question by:Lee Redhead
    LVL 50

    Accepted Solution

    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

    Author Closing Comment

    by:Lee Redhead
    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.

    LVL 50

    Expert Comment

    by:Julian Hansen
    Yup that about sums it up.

    You are welcome.

    Expert Comment

    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.

    Featured Post

    Looking for New Ways to Advertise?

    Engage with tech pros in our community with native advertising, as a Vendor Expert, and more.

    Join & Write a Comment

    If you have heard of RFC822 date formats, they can be quite a challenge in SQL Server. RFC822 is an Internet standard format for email message headers, including all dates within those headers. The RFC822 protocols are available in detail at:   ht…
    SQL Server engine let you use a Windows account or a SQL Server account to connect to a SQL Server instance. This can be configured immediatly during the SQL Server installation or after in the Server Authentication section in the Server properties …
    This video is in connection to the article "The case of a missing mobile phone (". It will help one to understand clearly the steps to track a lost android phone.
    This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

    746 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now