Announcing Password Rotation Policies: a feature you shouldn’t use
Typically, when we announce a feature, it’s a feature that we are excited about and want people to use. This feature is a little bit different and I thought it’d be interesting to explain what the feature is, why we don’t think you should use it (unless you have to), and why we built it anyway.
What is it?
You can set a password rotation policy for organizations in your PropelAuth project:
This will require users that are logging in to that organization to rotate their password every N days and to specifically choose a different password than the last X passwords they used.
You can configure both the period of time before they need to change their password and the number of previous passwords we check, and can choose different values for different organizations.
The problem with some password best practices
There are a number of different “standards” out there that provide guidance around passwords. You’ve almost certainly seen a ton of different implementations of these, like:
- Your password must be more than 8 characters
- Your password must have at least one special character, one number, and one uppercase character
- Your password cannot contain your username
- Your password is part of a previous breach
And each of the best practices typically came from either a technical requirement and/or an attempt to protect users from themselves.
But, over the years, general guidance on these topics has changed, and one of the most common reasons they would change was we’d learn that the attempt to protect users from themselves was having the opposite effect.
Take password complexity requirements, for example. The idea that requiring an uppercase letter, a number, and a special character would make passwords stronger sounds perfectly reasonable. In practice, what happened is people took a password they could remember and made the most minimal changes possible to satisfy the rules.
"password" became "Password1!", which technically meets every requirement while being trivially guessable. Bill Burr, the guy who originally wrote the NIST guidelines for password complexity, publicly said he regretted the advice.
Why shouldn’t you use this?
When people are forced to change their password every 30, 60, or 90 days, they don't come up with a brand new strong password each time. They follow patterns.
"Summer2025!" becomes "Fall2025!" becomes "Winter2026!" or, even more commonly, "MyPassword1" becomes "MyPassword2" becomes "MyPassword3".
Researchers at UNC Chapel Hill studied this and found that for users whose previous password was known, 17% of their new passwords could be guessed within just five attempts by applying common transformations. In a broader analysis, 41% of new passwords could be cracked in seconds if the old password was known.
NIST even updated their Digital Identity Guidelines in 2024 to say that organizations "shall not" require periodic password changes.
In practice, it’s better to prefer longer passwords, generated from a password manager, enforce MFA, and only require password changes if there’s evidence of compromise.
Why did we build it anyway?
We have customers in a lot of different industries, and not every industry is always using the latest and greatest when it comes to security guidance. The research and recommendations might be clear, but changing internal policies (especially at larger enterprises) takes time. Sometimes a lot of time.
A company might know that NIST no longer recommends password rotation, but their security team still has it in their policy, their auditors still check for it, and updating that policy is a six-month process involving committees and approvals and a whole lot of meetings.
We don't agree with password rotation as a practice, but we also didn't want to put our customers in the position of having to push back on their customers over it. If one of your customers requires password rotation as part of their security policy, that's a conversation between you and them, not something your auth provider should be making harder for you.
It's also worth noting that this is fully opt-in and configurable per organization. It's off by default, and if you do need it, you can enable it for just the organizations that require it without affecting anyone else.
We'd love a world where every compliance framework aligned with the latest security research. But that's not the world we live in, and we don't think it's our place to leave our customers stuck between a rock and a hard place. So here's password rotation, a feature we hope you don't need, but one that's there for you if you do.
