I have client who is adamant they want to store the last 4 used passwords for every user and force each user to change their password every 6 months to something not used before (i.e not in the last 4 used).

I have advised them not to implement any forced password change for the following reasons:

  1. Forcing a user to change a PW weakens the password in 90% of cases, especially a forced change that remembers the last 4
  2. Storing effectively 5 password hashes (4 previous, 1 current) for every user could be a nightmare should their ever be a data breach
  3. The system in questions already has many other well implemented security controls, IP whitelisting etc
  4. Not forcing a PW change is in line with the latest NCSC guidelines

Now I have explained this in detail to them but they still will not see sense.

My question: Is their another angle I can take here? Is their any points I have missed that will help my case?

NOTE: I am not looking at the technically of storing old passwords, I am trying to convince the client not to implement a forced password change, and am trying to construct the strongest possible argument.

  • I would spent my time securing the client systems in other places. Like implementing a decent complexity check or good log monitoring. And 6 month is not that bad for regular changes.
    – eckes
    Sep 18, 2017 at 0:40

2 Answers 2


Before you spend any effort trying to get them to change, consider they might be under a requirement you are unaware of. For example, if they are using these passwords to access a credit card environment, PCI DSS requires a periodic password change. This could be something completely out of their control.

If that's not the case, you can try referring them to the latest recommendations of NIST in SP 800-63B. In section Memorized Secret Verifiers (aka passwords), they say this [emphasis mine]:

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

The entire section on passwords is intended to be read and implemented as a whole, of course, but this recommendation stands on its own. The only complaint I have on the paper is that their recommended minimum length is only 8 characters, which is clearly not enough to withstand a brute force offline attack on password hashes that might be exposed in a data breach. To mitigate that, they do require stored password hashes be sufficiently protected against brute force attacks, such as 10,000 rounds of PBKDF2.

10,000 rounds of PBKDF2 is suggested for online password verification because the idea is to make it computationally expensive to verify a single password, while still allowing for real-time processing during the frequent occurrences of user logins. But note that old password confirmations would happen only during an actual password change activity, which should happen far less frequently than regular logins. And this opens an opportunity to improve your security.

Consider expending extra processing power during the process of password changing. Compute both the PBKDF2(password,10000) and store it in your "everyday password" table, and keep an archive of PBKDF2(password,50000) in your "prior password" table. When they log in again, compare them only against the "everyday password" table. When they change passwords, perform the lookup against all the entries in the prior password table; this will be much slower than a regular login, but because it's infrequent, it shouldn't disrupt your normal business. Once it's verified as unique, discard and replace the existing everyday hash with the new everyday hash, and add the new strong hash to the "prior password" table, rolling off their oldest prior password.

If it ends up that you can't talk them out of periodic password changes, try to get them to at least implement the strongest practical storage of "prior passwords".

  • Fantastic idea to significantly increase the work factor for prior passwords! Storing them as bcrypt cost 12 would be pretty cool. Of course, just switching to that for everyday passwords as well (if feasible) would be even better! :) Sep 18, 2017 at 1:22
  • PCI DSS specifically is not last 4 (and min length 7 and mix alpha+numeric but not necessarily special) every 90 days not 6 months. Of course there is no shortage of other authorities in various areas who impose similar (misguided) requirements. Sep 18, 2017 at 5:08
  • I know it's 90 days, I was just trying to present an example of a security standard interfering with current security best practices. Sep 18, 2017 at 13:03
  • @RoyceWilliams , if you can tolerate the performance hit if you increase your everyday password authentication bcrypt factor by 12, then you should be able to increase your prior password bcrypt factor by another dozen or so above that. Sep 19, 2017 at 11:31
  • @john-deters, since the work factor increase by a power of two with each increment ... I doubt it. :) Sep 20, 2017 at 13:46

One other point you haven't considered is that your overall password security is at its most vulnerable during a password change. Not considering the security of the systems, this is a time when a social engineering or Trojan horse attack can dupe your users. Enforced rotations increase your attack surface. This is the risk to balance against a password being stolen today and misused a year or two later.

Not the answer you're looking for? Browse other questions tagged .