That's correct. PCI DSS section 8.2.4(a) requires that passwords are changed at least every 90 days.

Other requirements from the same section: retain old passwords to disallow dupes for at least 5 cycles, passwords must be minimum 7 chars, and contain both alpha and numeric.

You might be able to justify non-compliance with a compensating control, but I've never heard of anyone who tried it.

Note that this only applies to employees who are in PCI scope. Most internal staff are not, and should not be!

Similar policies are common for all users though. They pre-date PCI (which is how they became part of PCI DSS) and now PCI's retention of these policies justifies continued use elsewhere. The tail wags the dog.

> You might be able to justify non-compliance with a compensating control, but I've never heard of anyone who tried it.

I just did similarly within a SOC2 audit. I sent the auditors a list of 50+ articles and references i've been maintaining for years saying that password changing is a bad idea (this article is on the list) from many different sources. I never heard back and the item was marked approved by them.

Can you please pop this list of articles into pastebin and paste it here? tyvm

This hasn't been updated in a while but there's plenty of references:

https://gist.github.com/technion/65c652194fb1427e6828ea23ff4...

Also, https://www.troyhunt.com/passwords-evolved-authentication-gu...

forcing https://www.washingtonpost.com/news/the-switch/wp/2016/03/02...

regular https://www.wired.com/2016/03/want-safer-passwords-dont-chan...

password https://practical365.com/security/microsoft-recommending-non...

changes https://www.scmagazineuk.com/end-password-expiry/article/147...

is https://www.sans.org/security-awareness-training/blog/time-p...

a https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...

bad https://arstechnica.com/information-technology/2016/08/frequ...

idea https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...

can https://www.schneier.com/blog/archives/2016/08/frequent_pass...

you https://cryptosmith.com/password-sanity/exp-harmful/

please https://www.zdnet.com/article/changing-your-password-regular...

stop https://www.ncsc.gov.uk/articles/problems-forcing-regular-pa...

this was one of the more cheeky version I sent to a vendor.

Would you consider sharing it? Might be useful for others in the same boat.

>Furthermore, you must retain old passwords to disallow dupes for at least 5 cycles.

More cynically: password reuse is allowed after 5 cycles.

I've actually known people who, when required to change their password, would change it 5 times in a row, then back to the original password in order to keep using it.

Guilty as charged.

It's why mandatory change policies are so stupid. Users will always sacrifice security for convenience.

Even those that know better.

This is why many systems - I've seen it with Microsoft and Salesforce - set a "minimum password age". Which is usually a minimum of 1 day.

This way, you can't change your password more than once a day. This makes quickly cycling through to get back to your original password hard.

This is amazing: "guaranteed at least 24h of exploiting a recently compromised account or your money back"

Yeah, I've tried that. First day in my new job. “Here's your PC. Your user name is [some initials] and your password is abcd1234". I sign in and immediately proceed to change my password to something that doesn't suck. I keep getting an error message about my new password not meeting the complexity requirements. Super confusing... I give up.

Next day: I can now change my password.

Turns out that I couldn't change my password the first day because it had already been changed to abcd1234 that day. I was not impressed.

It is internal joke, you 'forgot' your password, so you get something like 'Spring2021' from IT as password reset. Now you pick a target account, trigger account lockout. Most of the time, the target is confused and gets a combo, account unlock and password reset. Now the IT guy who does password reset ... uses seasonal passwords which of course can't be changed for 24 hours.

Oh this is clever, I’ll use that next password rotation so that my password doesn’t change in effect. We must change every 60 days where iWork, and it doesn’t work well so some systems still use the previous password, some still use 3 passwords ago, etc. It’s random though, you never know in which systems the password change will take and in which it won’t)

Worse is when you're developing software against those other systems, and within a few minutes of logging in, your account is now locked out.

I went to a college with that problem. After your mandatory password change, any device autoconnecting to wifi would trigger a lockout. Since the same password was also use to log into network computers, there was no way to visit the webapp to unlock your account.

Unless you had data on your smartphone or had a friend who was logged in, you were SoL.

Slightly more tech-savvy users will just use a password manager... called "passwords.txt" file saved on the desktop.

Won't work for the Windows password, but with more and more corporations outsourcing their tools to the cloud, system account password is rapidly becoming the least important one (like it already is for most people's personal devices).

Back in the day, I changed my password 13 times every month in order to reuse the same one again. Super secure!

Absolutely. Worked in SAP (the variant used by last place anyway). Don't think it was as many as five, three maybe, or change it and change it back even.

Yep, Its very secure, because nobody would use:

    P@ssw0rd!
    P@ssw0rd!2
    P@ssw0rd!3
    P@ssw0rd!4
    P@ssw0rd!5

I once used a system that stored old passwords as plaintext and searched for substring repetitions. Horrible.

Microsoft has that.

Not plaintext, but encrypted (not hashed) with the idea that they can be used for things like that.

https://docs.microsoft.com/en-us/windows/security/threat-pro...

This is a good idea, if the passwords are the ones people change *from* (i.e. once you change your password, it gets into that list). This way nobody can use the password anymore (with the idea that it is a weak now, for any reason).

This is selfish, though. If that database of passwords leaks, they are prime candidates to test on *other* sites.

If you encrypt the prior passwords using a key derived from the current password, you're enabling this sort of check on password change without really sacrificing security, don't you?

> If you encrypt the prior passwords using a key derived from the current password,

How can you do that with a prior password if you didn’t store it as plaintext when it was current? You can’t encrypt something you don’t have. Unless you are encrypting the old hash, not the password.

You would have it during the password change if you did old-new-new_again, yeah?

Yeah that was the idea. I guess a lot of apps don't actually do that and just email you password reset links, in which case you can't actually recover the old password. :<

This leaks data if a collision can be found and exploited.

Assuming the user uses the password in other places, this can be a bad thing.

The excellent (or horrible, depending on which end you're on) pam_pwquality[1] module for Linux allows rather fine-grained enforcement of how much a new password must differ from the old password.

1. https://www.systutorials.com/docs/linux/man/8-pam_pwquality/

That's why those of us in the security industry have to say "compliance is not security" whenever PCI is brought up.

PCI is just so asinine it made me want to poke my eyeballs out when I had to go through it (Level 1 Service provider). In some situations it actually prevents you from being more secure.

One of the reasons why I want the Credit card cartels to die.

well I've known more clever users, guess what you need to do if your password needs to change every 90 days, but you need to have a different password for at least 5 cycles?

correct, you do it like that:

- h@se2003 - h@se2006 - h@se2009 - h@se2012 - h@se2103 - h@se2106

you get the point ;-) bonus points for encoding the username into it and making it a thing for the whole company, yeah very secure!

This is how I used to do it. Just slap the year and Q on the end whenever it wanted me to change it. End of the quarter gets a bit tricky if things don't line up but it's mostly muscle memory by then

Sup3rdup3rp4ss2021Q2

This is why when I built our systems, I did most of them using a combination of public/private keys and TOTP 2fa. Also severely isolating those systems so that the list of people who need access is as small as possible.

It's orders of magnitude less of a pain in the ass than password cycling.

I've worked at places that would disallow re-use for the last 30 passwords. When you're forced to change every 3 months you're looking at a company maintaining a password history for over 7 years.

How is that managed? Are they hashed or stored in the clear? If they were hashed, then they would have to know which algo to use for a password at a point in time otherwise they would lose that data whenever they switched the hashing mechanism.

And when that data inevitably leaks, attackers have a nice table of passwords and metadata that will easily help them out in other places.

A solved problem with public key crypto, where you are in full control of the secret and can take your own steps to protect that.

I believe Active Directory just stores the hash like it does for your current password. Yep, if you crack the domain controller or grab a copy of the backups and get those hashes then all the bets are off. You also get their current passwords because they're there as well, so its not like having the old ones makes anything worse. And of course, if you do have admin privs on the domain controller, you can do a lot better and easier things than bothering with those hashes anyway.

This is why the modern approach is something you know (password, PIN) plus something you have or are given (time code, texted code, face, fingerprint) for authentication. For environments with MFA, regular password changes seem like a solution that's no longer needed. Ours is a long password changed once a year and I imagine the mandatory change will be phased out eventually.

That only applies to Level 1 and/or SAQ D merchants (who are storing card numbers) which the vast majority are not.

This is true. As John (Cougar) Mellencamp sang: "Hold on to SAQ A / As long as you can ..." :)

wouldn't MFA/OTP be sufficient to compensate?

PCI DSS section 8.3 requires MFA explicitly.

The logical assumption is that PCI does not consider satisfaction of 8.3 to be a compensating control for the requirements in 8.2.4 -- however I've never heard of anyone who made the attempt.

...

PCI is a weird mix of requirements, evaluations, and compensations. The final authority is the PCI org themselves (i.e. the card networks), but the eval is performed by PCI-approved third parties, for report to your business partners. Requirements are extensive but not always definitive. Compensations are subjective, at best. Enforcement is sketchy but can be devastating.

The usual approach is to comply, comply, comply, and accept that some of it is policy theater, but it's rarely bad policy.

Password rotation is bad policy, but ironically it's mitigated by MFA!

I’ve had a number of Level 1 merchants/service providers ditch PCI password complexity/rotation rules, and I’ve always managed to get it accepted by QSAs.

The compensating control is to implement the full NIST recommendation (like enforcing an extra long password length, monitoring for compromised passwords, having a documented passphrase policy, etc...), and in your compensating control worksheet describe how those practices go above and beyond the DSS requirements. That bits quite simple, because there’s plenty of authoritative resources you can reference to justify that position.

The harder part is coming up with a justification for why you need to implement that compensating control. Because a compensating control can only be implemented to address a legitimate business/technical constraint. But that bit really just takes a little creativity.

Those are the defaults for the little authentication management app I wrote a year and a half ago... Defaults are NIST guidelines, with options to implement "typical" adjustments, like rotation requirements. Default min-length is 12 iirc, and does a check against zxcvbn and the haveibeenpwned list. zxcvbn is displayed/advisory by default, can be set to required and the pwned list is enfoced, but can be toggled off.

Also, use of the term "passphrase" instead of "password" and recommending a short sentence with multiple words, casing, spacing and punctuation.

Rumors has that the next PCI-DSS revision will change that requirement.

It wouldn't surprise me if this were a regulation requirement, since most very large companies I've worked with all have pretty much identical password expiration policies.

Change travels very slowly - some years ago NIST and everybody else's recommendations used to require password rotation, so lots of policies and habits of policy writers/enforcers and educational materials still echo the old recommendations.

This requirement can come from lots of places. I remember at the last place I worked, we had to get audited for SOC2 compliance and password expiry was part of the requirement. I imagine these things lag behind the recommended security guidelines by quite a few years.

It feels extremely negligent of third party auditors to recommend (and sometimes require) companies to enforce worse, obsolete security practice.

SOC 2 is defined by the American Institute of Certified Public Accountants. Having computer security defined by accountants seems crazy, but is in the style of the bureaucratic mess of modern enterprise.

Don't recall for SOC2 specifically, but a lot of the time, "best practices" suggestions and the requirements weren't the same, and people codified the suggestions internally, or the reviewers/auditors would.

One thing to remember that large companies love things which they can point to if something goes wrong. PCI isn't regulation but it's widespread because the credit card companies require it. Depending on the industry you might also find CIS pretty common (https://www.cisecurity.org/) and the U.S. federal government space will mention STIG (https://public.cyber.mil/stigs/).

These are built into common assessment tools so you'll get identical policies down to things like byte-for-byte identical PAM module config because most places just licensed one of these tools and demanded everyone use it.

I've also seen it written into business contracts with clients. Which makes it almost impossible to change, because doing so would require both sides to agree to pay for an expensive (and irksome) exchange between their respective legal teams.

Working with govt agencies, this is somewhat painful. "Must be AES256 encrypted at rest." is one of my favorites.

Regulation is usually pretty light on specific technical measures, it says something vague like "you must follow best practices" and then there's industry consensus / rumors about what those are.

That's really dependent on what regulation you're talking about. The FCC has some extremely specific rules in Part 15, for example.

PCI is, practically speaking, nearly the same as an actual regulation, given how stringent and widespread it is.

this.

I wonder if Microsoft employees (all or portions) have to rotate their passwords due to PCI compliance despite Microsoft's stance on the subject.

Not any more, as of a year or two ago? We finally updated our internal structure to follow the NIST guidelines we helped write.

I asked my company IT why we still have mandatory rotation and I was told it is due to PCI.

I have the feeling that HIPAA requirements are also another driver.

HIPAA isn’t nearly as prescriptive as PCI. It’s more about defining what PHI is, and what the consequences are for mishandling it.

> HIPAA isn’t nearly as prescriptive as PCI.

For odd historical reasons HIPAA is passive-aggressively prescriptive through the definition of secured PHI in guidance issued under the HITECH act, whereas the basic Privacy and Security Rules are less so.

> It’s more about defining what PHI is, and what the consequences are for mishandling it.

Well, the Administrative Simplification part of HIPAA (which is far from the whole thing, and which the Privacy and Security pieces are in turn smaller components of) are really more about standardizing and encouraging use of health IT in multiparty interactions in healthcare. The Privacy and Security aspects were included largely to mitigate public fear of shared, common-format digital transactions and records being a privacy risk.