Forcing periodic password changes has been against NIST recommendations since 2017
[PDF] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator. (page 14)
What's new in 2024's draft is changing this from "SHOULD NOT" to "SHALL NOT"
I work with several organizations that force password changes. I add month/year of change to the "base" password every 2 to 3 months. It's a total waste of time.
The most annoying thing in the past years has been some of my government assistance accounts and other things that have limited character set definitions and forced rotation. Even though I use a password manager that's local on my computer for this stuff it's still utterly frustrating because of the way they handle it. I've had to call up and reset passwords because something in the middle during the rotation or before the rotation even began and I ignored the changing of the password for long enough that the account was just unusable.
do you see how what I end up having to do absolutely circumvents the security of rotating a password.
Would it make sense to apply the same recommendations to expiring certificates?
Not if you have security compliance rules you need to comply with in order to get customers, and those rules stipulate a password rotation schedule!
Perhaps anecdotal, but I have never got any negative response on answering “no, we do not enforce password rotation as this is against NIST recommendations.”
Unfortunately that's not how it plays out in most large organizations, which have separate network, hypervisor, security, etc., teams. Everyone works off a playbook, whose origins are usually lost in time and space.
If you want them to change the playbook, it'll involve some schlub having to run from pillar to post between those organizations, trying to get everyone to agree to a change to this policy, and you can bet he or she is not paid or motivated to do this. If another vendor comes along who will go with the flow, they get the sale.
Every organization I’ve worked for has been able to change policies at will. I’ve written them for half a dozen. I don’t particularly like writing policies but if you do you’ll be able to remove the absurd and broken parts.
You don't get to pencil in your own policy when the organization must conform to standardized compliance rules (such as HITRUST for health related companies) that mandate certain policies, or risk losing customers who look for compliance to these rules. These guidelines can take years to catch up to modern best practice.
Naturally, Windows 11 seems to sometimes auto enable password expiration.
If password rotation is a bad idea, how do you deal with password compromises and credential stuffing attacks? Passwords tend to leak eventually.
Reset the passwords that have been compromised rather than resetting them for no reason other than how long it's been since they were set up.
But then you are engaging in a race against the attacker that you will probably lose. Attackers use leaked creds before sharing them publicly.
You always are engaging in that race, whether you force users to change their passwords periodically or not.
Simple--you work towards making password compromises less fruitful.
MFA is a step in this direction, and done right, it should be able to alert admins and users alike that compromise and stuffing is in- progress.
Password managers and generators can make unique passwords easy as pie, thereby reducing the rampant reuse, and unwillingness to reset passwords when necessary.
Magic links and passkeys can make passwords obsolete. CAPTCHAs interfere with automated stuffing operations.
The largest services are also developing sophisticated measures of device fingerprinting and trust, of which attestation is the endgame. Y'all don't enjoy credential stuffing or data breaches, but love rooting and rail against attestation, so do you want to have your cake and eat it too?