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.
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.
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)
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).
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.
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.
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. :<
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.
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?
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
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.
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.
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.