Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


Storing users password history securely with salt

Posted on 2012-08-28
Medium Priority
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
  • 2
LVL 61

Accepted Solution

Julian Hansen earned 2000 total points
ID: 38340280
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
ID: 38340331
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 61

Expert Comment

by:Julian Hansen
ID: 38340346
Yup that about sums it up.

You are welcome.

Expert Comment

ID: 40432750
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

[Webinar On Demand] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this article I will describe the Copy Database Wizard method as one possible migration process and I will add the extra tasks needed for an upgrade when and where is applied so it will cover all.
This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
In a question here at Experts Exchange (https://www.experts-exchange.com/questions/29062564/Adobe-acrobat-reader-DC.html), a member asked how to create a signature in Adobe Acrobat Reader DC (the free Reader product, not the paid, full Acrobat produ…
Kernel Data Recovery is a renowned Data Recovery solution provider which offers wide range of softwares for both enterprise and home users with its cost-effective solutions. Let's have a quick overview of the journey and data recovery tools range he…

564 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