My understanding is the biggest driver of still having mandatory password rotation is PCI (the payments security requirements, not the bus)
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.
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!
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.
Also, use of the term "passphrase" instead of "password" and recommending a short sentence with multiple words, casing, spacing and punctuation.
P@ssw0rd!
P@ssw0rd!2
P@ssw0rd!3
P@ssw0rd!4
P@ssw0rd!5Not 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...
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.
Assuming the user uses the password in other places, this can be a bad thing.
This is selfish, though. If that database of passwords leaks, they are prime candidates to test on *other* sites.
1. https://www.systutorials.com/docs/linux/man/8-pam_pwquality/
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!
Sup3rdup3rp4ss2021Q2
One of the reasons why I want the Credit card cartels to die.
More cynically: password reuse is allowed after 5 cycles.
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.
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.
Unless you had data on your smartphone or had a friend who was logged in, you were SoL.
It's why mandatory change policies are so stupid. Users will always sacrifice security for convenience.
Even those that know better.
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).
It's orders of magnitude less of a pain in the ass than password cycling.
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.
https://gist.github.com/technion/65c652194fb1427e6828ea23ff4...
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.
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.
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.
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 wonder if Microsoft employees (all or portions) have to rotate their passwords due to PCI compliance despite Microsoft's stance on the subject.
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.