Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an application with a user database. The database stores the password using a bcrypt hash with a randomized salt.

How can I implement a password history set (to prevent password reuse) in a case like this?

If I have the traditional 3 field password reset (enter current, enter new, confirm new) I could store the current one as I replace the old with the new. However, then I have the case of a forgotten password. My users could go and do an self-service auto reset and reuse their passwords over and over again.

The stored passwords would be encrypted, but with reversible encryption making them less secure.

share|improve this question
up vote 8 down vote accepted

Store the old salt and hash values. Hash the new input with any old salts and see if they match.

If it worked for checking the password when they logged in normally, it will work for checking if the password has been used before too.

share|improve this answer
wow, I completely over-thought this one. – Snowburnt Dec 31 '13 at 15:29
@Snowburnt - yeah, we all do that from time to time. Glad I could help. – AJ Henderson Dec 31 '13 at 15:48
There's some concern that by storing the old hashes, you're giving someone who steals your password db the opportunity to make an offline attack on old passwords, which could conceivably harm the user or lead to a guess at the current password ( I suppose perhaps you could make a Bloom filter of the old hashes or something, at the cost of false positives, with the parameters set such that someone trying to guess old passwords using the filter will find far more false positives than true ones. – Steve Jessop Apr 2 '15 at 23:23

If password1 = password2, then hash(password1, salt1) = hash(password2, salt1).

In other words:

  • Bcrypt the new password with the same salt and iteration count.

  • Compare the hashes.

  • If the new hash is different from the old hash, then everything is okay (according to your criteria), and you can simply re-hash the new password with a new unique salt and store it in the database.

  • If the new hash is the same, then the new password is the same as the old password. Tell your user to choose a new one.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.