Password expiration and compliance (ISO, NIST, PCI, etc)

Question

I'm quite confused about what is the current state in 2017 for the idea of password expiration/rotation especially related to security certifications as ISO, PCI, etc. I keep reading that password expiration is not very useful, but I've found several slides where it still seems to be part of the policies/rules (for ISO and PCI).

There is one specific part that seems a bit unnatural to me, and this is (assuming that you have a strong password policy in place, which we already have) the need to store the old password hashes in your database to prevent users from setting an old password when the current expires.

I have always (wrongly) assumed that the expiration was approaching the issue using a social angle, a way to tell users that passwords were important. So, the new password had to be different from the current, but without checking historically previous records.

I had the intuition that this wasn't safe, but it seems that big corporations use it know to provide UI hints (although I think it's fair to assume that these organisations may have a much better control of their backups than smaller companies do, where mistakes could be more likely).

I've read an article in which it would seem that NIST will no longer enforce password expiration. Anyway, now that my system is going to have password expiration due to requirements, I was thinking that it would make sense to match, to some extent, the requirements present in these certifications.

• What is the state of password expiration/rotation in these certifications (ISO, PCI, etc) in 2017?. Is it still part of them?.

• Do they target/mention a number/period of old passwords that you have to store?.

I don't have access to any original documentation as we are not in any adoption process, but it would be good to know even generally speaking.

Answer 1

The current version of PCI DSS is 3.2.1*, and in section 8.2.4 it requires users to change their passwords every 90 days. Section 8.2.5 requires that passwords must not be the same as any of the four previous passwords (note that it does not prescribe how this is to be accomplished; the standard does not specifically state the "storage of hashes" is required.)

However, this document is clearly not based on state-of-the-art password security because section 8.2.3 of the same document requires passwords be a "minimum length of at least seven characters" and include "both numeric and alphabetic characters." Modern computers can run password cracking software that will brute force a 7-character alphanumeric password in seconds. Because of this poor requirement alone, it is hard to believe that any of their password security requirements are based on research, or are effective.

That said, our knowledge that this standard is not good enough doesn't mean we can ignore it. No matter what, we're stuck with a 90 day rotation policy, whether or not it provides any useful defense against an attacker, or whether or not it exposes our users to inconvenience or additional risk, because we are contractually obligated to meet the PCI standards. Instead, since we are aware that the standard is inadequate in this regard, what we need to do is implement a responsible security policy in our organizations that address the known problems (requiring a 14 character password that meets the other draft NIST recommendations in 5.1.1.2, for example) that still complies with all the requirements of the DSS. Having an organizational security policy and following it is Requirement 12 of the DSS, and it's actually a very good one.

* PCI DSS 3.2 was current as of 2017. In 2018 the version was updated to 3.2.1, a minor update that made no changes to password advice.

Answer 2

To answer your Questions first, from an ISO 27001 perspective, it does not prescribe what should be your Expiration duration, neither does it specify how many old Passwords you should retain.

Instead, it provides generic guidelines on Password Management. For sake of compliance & to satisfy Auditors, it is better to have a Password expiration duration of no more than 90 days, & retain at least last 2 Passwords to prevent re-use.

ISO 27k1 does explicitly mention that we should "maintain a record of previously used Passwords and prevent re-use" but it does not specify how many of them should be retained.

Entire control & implementation mentions something like this.

Control A.9.4.3

Password Management System shall be interactive and shall ensure quality Passwords.

As per ISO 27001, a Password Management System should (with my own comments added).

• maintain accountability by enforcing use of Individual User IDs and Passwords.

• Users should be able to select & change their Password whenever necessary, basically meaning that Users have control over their Password.

• include a confirmation procedure to allow for input errors for times when Users make a mistake logging in.

• enforce good quality Passwords, which should ideally be defined in your Password Policy & enforced in your Application.

• force Users to change their Passwords when they log-on for first time, without which Users are unlikely to change their default Password at all. Force-update of Password should be implemented when it is reset by Admins too.

• enforce regular Password changes, which should ideally be 90 days or less. Auditors seem to prefer 30 days but that may be too much.

• retain previously used Passwords and prevent their re-use, but it is not specified how many Passwords should be saved.

• not display Passwords on the screen when being entered, which is logical.

• store Password data separately from Application System data, although I am unsure how practical this is to implement from an architecture point of view.

• store and transmit Passwords in protected form, like SSL for online applications.