4

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.

TrickyDupes
  • 2,829
  • 1
  • 13
  • 27
  • 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 '17 at 00:40

2 Answers2

4

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 5.1.1.2 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".

John Deters
  • 33,897
  • 3
  • 58
  • 112
  • *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! :) – Royce Williams Sep 18 '17 at 01: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. – dave_thompson_085 Sep 18 '17 at 05: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. – John Deters Sep 18 '17 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. – John Deters Sep 19 '17 at 11:31
  • @john-deters, since the work factor increase by a power of two with each increment ... I doubt it. :) – Royce Williams Sep 20 '17 at 13:46
  • *" 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"* The standard also talks about allowing users to paste password - so they can use password managers. With bcrypt cost of 12, and the fastest hashcat in existance, that works out to 718 billion billion billion years to crack (because they also specify allowing all unicode characters - of which there are 109,384) – Ian Boyd Jan 23 '19 at 16:44
  • @IanBoyd , if you tell an American to enter an 8 character password, he will not select randomly from the full set of possible Unicode characters- he will draw only from the 26 letters he knows and uses every day. That’s the set an attacker would test. – John Deters Jan 23 '19 at 18:29
  • @JohnDeters The point was that the standard is the minimum recommended; which works fine. If you want something more: that's fine too. Personally requiring `n` characters is also the wrong approach. The goal should be [*"takes estimated 50 years to break"*](https://security.stackexchange.com/a/201965/3874) - not length. Not composition. Not complexity. Not expriration. – Ian Boyd Jan 23 '19 at 20:02
2

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.

John Deters
  • 33,897
  • 3
  • 58
  • 112