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