Comment by montebicyclelo
2 days ago
Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
Many (most?) companies still do it, despite it now not being recommended by NIST:
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
https://pages.nist.gov/800-63-3/sp800-63b.html
Or by Microsoft
> Password expiration requirements do more harm than good...
https://learn.microsoft.com/en-us/microsoft-365/admin/misc/p...
But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).
The requirements usually don’t come from IT.
It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach.
Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.
I belonged to an organization that had password complexity requirements. That's normal and understandable. However one requirement was that no part of my password could contain a three character subsstring that was included in my full name. I won't give my real name here, but sadly it includes some three letter subsequences that are somewhat common in many English words. I can understand a policy that prevents someone from using "matthew1234" as Matthew Smith's password, but this rule also prevents such a person from using "correcthorsebatterystaple" because it has 'att' in it.
Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
> Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.
I wonder if some of these constraints are to try to find a way not to pay out on the policy.
1 reply →
Just an unbreakable law of the universe.
"Why did this stupid shit happen? Oh, it's money again."
It's not money but inertia of very large systems. All these password changes cost money as well. If anything it's a market failure that insurance companies seem to have too little incentive to update their security requirements. This would likely be solved by reducing friction with both evaluating insurers in detail and switching between them.
4 replies →
Not money; incentives
Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep track of the change interval. It also adds no security whatsoever! A user could almost certainly get away with Password2025-06, etc.
I once wrote a script to change my password randomly X times and then back to my original password. Worked like a charm.
There are policies to prevent changing the password more than once a day to prevent that. I've encountered it in several places
9 replies →
Password changed.
Password changed.
Password changed.
Error at : broken pipe
I’ve personally experienced the password change require that “more than X characters be different than the old password”
Um, that's a really bad sign...
11 replies →
I just let the keyring roll a completely new password. For some reason, all of my employers do require this insanity, but not on the one password I have to actually type.
I once had an employer that required us to use passworded SSH, and disallowed SSH keys, because they couldn't enforce that the SSH keys were passphrase protected, so just turned that option off.
They said it was a PCI requirement, or something.
11 replies →
Whenever I don't have to type it, that's what I do. It's the login (or password manager password) needing this counterproductive crap that gets the "append a date" treatment. It's a 10-word diceware passphrase, only used for that login anyway, it's not getting breached if it's stored in even a remotely secure manner (even an unsalted hash would be safe).
They do it because their IT departments are checklist monkeys with no actual brainpower there, AND/OR they have cybersecurity insurers that mandate it who also have nobody with actual brainpower working there.
> But these don't seem to be authoritative enough for IT / security,
As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.
Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.
Sometimes when I log into a random website and I see a forced password reset, I wonder if it has been compromised, rather than setting a time-based expiry.
If a site owner knows that certain accounts are part of a database breach or something, a reasonable step would be to force the users to change the password at next login.
Another common reason to do a force password reset is if they've moved authentication providers and were not able to bring their hashes along. Some providers don't allow for hash export (Cognito, Entra).
Or just if they changed to a more secure hash algorithm themselves and want to upgrade users still on the older insecure one.
3 replies →
Last time I brought this to our cyber folks, they pointed out that PCI standards require password rotation. So it depends upon which auditors you care about more.
This requirement is in section 8.3.9 of the PCI DSS[0], and only applies to single-factor authentication implementations, two-factor auth removes this requirement.
[0] https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard...
Your broker/bank still needs to do it, unfortunately... someone please fix this :(
[0] https://www.finra.org/filing-reporting/entitlement/password-...
9 replies →
I’ve always said “lockout turns a possible password guessing attack into a guaranteed denial-of-service attack”.
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
I think a lot of people in IT know these things but having a 'strict' auth policy makes them seem competent so they just go with that. Besides there is not much incentive to make authentication efficient since the frustrated users are a captive audience not paying customers.
I just had this argument with a state wide government website. I have to log in to this site maybe once per year to update contact information and update a few fields. Unfortunately, that site silently deactivates your account automatically every 90 days. So I'm forced to change the password literally every time I log into the dumb thing.
They refused to establish MFA or passkeys - and instead insist that "NIST is the minimum recommendation for cybersecurity... and we take cybersecurity very seriously... to ensure the safety and security of the citizens... therefore we will not change our policy on mandatory account lockouts or password change requirements."
if my password has not been leaked it's insane that providers think i should rotate it, but this still seems to be standard practice for some completely baffling reason
There’s weird math that says your password or generally a secret key is more secure if it’s existed for less time (generated fresh) because there hasn’t been as much time to brute force it. I don’t believe it but some hardcore types do.
That might apply to short passwords but passphrases are recommended and if they're >20 characters then brute forcing is not going to make meaningful progress toward them while we are all alive.
> I don’t believe it but some hardcore types do.
… which is why the password has sufficient entropy such that it will take until the heat death of the universe to brute force it. We're 3 months closer to the heat death of the universe … oh no?
Time based expiry (“freshness”) is not about likelihood of brute force. Brute force prevention is handled by delay/lockout policy for online systems, and by password complexity rules or key length/cipher combinations. Nobody sane uses such rules in such a way that make brute force “slightly impractical”- security practitioners always choose lifetime-of-the-universe-scale complexity if given a choice.
Instead, expiry is about “what are the chances that the secret has already leaked” and about choosing an acceptable compromise between rotation frequency and attacker loiter time - assuming that the system hasn’t been back doored, let’s put an upper limit on how long an attacker with the secret has access. And incidentally it also means that if you somehow fail to disable access for ex-employees, that lingering access will eventually take care of itself.
But as the article points out, expiry has always been controversial and it’s not clear that on balance expiry is a good control.
it's BSD /etc/passwd being 666 or something, so anyone could brute force it in 180 days, therefore passwords has to have max complexity within 8 bytes limitation and rotated every 180/2 days... who's even started using computers before it was patched?
>I don’t believe it but
you have to believe it, it's true, you just think it's not the greatest threat or that the response to mitigate it (for example, using a pattern of temporary passwords to facilitate remembering them) would be worse than the disease.
7 replies →
These recommendations live in a mythical world, but not in a company.
In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.
In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.
This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).
A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.
And then you have trauma that will say "we cannot change the password because we don't know where it is used".
Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.
IT seems to be a haven for minor dictators to enact their power fantasies
Stuff like ISO27001 still demands it. We have to rotate passwords, against modern cybersecurity practice, in order to comply with an information security standard.
ISO 27001 doesn't say this. The control implementation guidance (ISO 27002) specifically cautions against requiring frequent password changes.
Most frameworks, at least most that I am aware of (north america) have removed password rotation requirements entirely, or have exemptions in place if you have MFA, use risk-based access policies, etc.
Often when people say this, they are parroting their assessor. But not every assessor graduated at the top of their class, or cares to stay updated, or believes that they know better, etc.
1234abcd@ it is then for all my accounts.
Password rotation does nothing more than get you to use
I'm becoming pretty convinced that at least in the corporate space, we'd be way better off with a required 30 character minimum password, with the only rules being against gross repetition or sequences. (no a * 30 or abcd...yz1234567890 ). Teach people to use passphrases and work on absolutely minimizing the number of times people need to type it by use of SSO, passkeys, and password managers. Have them write it on a paper and keep it in a safe for when they forget it.
This is a better use of the finite practical appetite for complying with policies than the idiotic "forcibly change it every 90 days" + "Your 8 character password needs to have at least one number, one uppercase, and one of these specific 8 characters: `! @ # $ % ^ & *`"
By the way, to quote Old Biff Tannen, "oh, you don't have a safe. GET A SAFE!"
Don't tell them. I don't want to have to enter 30 characters. And it does not help for the people you'd need it for anyway.
Better?
No, just longer to type. You can't fix stupid people by making the life of non-stupid people worse.
All you do is for non-stupid people to stop caring and do the easiest thing possible too.
6 replies →
In the corporate space you should move away from passwords entirely.
Smart cards have had pretty solid ecosystem support for the past two decades thanks to the U.S. Government and HSPD-12, and now we’ve got technologies like webauthn that make passwordless authentication even easier.
3 replies →
In the enterprise, the cost of inconvenience to users is effectively zero. Perhaps even negative as security theater can be a pretty effective way to convince management that something is being done.
There's one weird trick to get people to have strong passwords (even if you force rotation): don't allow them to pick their own passwords. Randomly generate the passwords for them.
1 reply →
Preach. Gmail doesn't force password rotation, and one can just imagine the type of attacks they must sustain...
Unfortunately corporate policies evolve at glacial speeds...
I’m doubtful a 30 digit minimum password is a meaningful improvement over a 20 digit password here. Meanwhile actually typing in very long passwords adds up across a workday/year especially with mistakes.
5 replies →
"Your password is too similar to your previous password"
Hmm, how would you know that.
4 replies →
Bad habits are hard to kill.
Sometimes you just cant convince people that something is no longer recommended.
You don't really need to convince people who implement it. You need to convince people creating certification/law, so PCI/SOC2/whatever. I'm still posting every time something like "for the record, I know we have to legally do this, but it's pointless and actually makes us less secure" for a few things.
been thinking same every time it asks me to reset without warning. i just assume breach and rotate everything linked to that email. if it’s not a breach and just some dumb policy, then congrats they made me waste 30mins securing nothing.
It honestly forces me to keep a Post-It on my monitor with a hint to this season's new password suffix.
Most SOC2 vendors still require rotation, it is unbelieveably frustrating.
Jesus, it was so annoying so I kept appending a letter after each password reset -> a through z
thankfully my current company let me keep my password for the last 3 years
Password similarity rule was not enforced ?
Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?
9 replies →
> Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT.
That is extremely annoying.
On the other hand if I was a manager and that happened to someone I managed we'd definitely have a conversation where I would acknowledge that forced password rotation is idiotic, but also point out that our password expiration is 90 days after the most recent change, which is 12 weeks and 6 days, and ask how come they don't have a "deal with stupid password expiration" event on their calendar set to repeat every 11 weeks?
That gives them 13 days warning. Vacations can be longer than 13 days, but I'd expect that when people are scheduling vacations they would check their calendar and make arrangements to deal with any events that occur when they won't be available. In this case dealing with it would mean changing the password before their vacation starts.
I don't expect people to go all in on some fancy "Getting Things Done" or similar system, but surely it is not unreasonable to expect people to use a simple calendar for things like this?
The fact is that you might have an employee who is a real expert in 3rd century archaeology, but scheduling and password changes just aren't what they are here to do. They don't want to do it, don't know how to do it, and don't want to learn how to do it.
So when they accept an invitation to give a lecture six months from now on the discoveries at the Gudme Hall Complex in Denmark how do they arrange to make sure they will show up?
[dead]
Hot take, password requirements are a necessity to prevent id10t errors.
Another hot take, calling them passwords instead of pass phrases was a mistake.
People have no problem making a secure pass phrase like 'apophis is coming in 2029’.
It uses special chars and numbers, but some websites would reject it for spaces and some for being too long.
I say these are hot takes despite aligning with NIST because I've never seen a company align with them.
"password too long" for password shorter than a megabyte is the most idiotic error ever created.
It only makes sense in HTTP basicauth and other system that keep plaintext passwords.