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.
It absolutely was/is.
To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.
> 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.
we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!
and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.
is a judge going to think the same way if insurance doesn't pay and you take them to court though, in the event of a breach, etc.
After all it's perfectly possible to do interior work in your house that isn't up to code, but if it burns down in a fire, the insurance company will investigate and may not pay out if they find out.
in this case I'd be more worried about being in court trying to explain why we knowingly used an inferior approach (forced password changes) when we knew the newer approach resulted in higher security... that is a vastly different analogy than being "out of code". additionally, noting the deviation from the old, less secure standard up front (in our HITRUST submissions) and with our customers (in their vendor questionnaires) provides evidence that we are going above and beyond vs. shirking a duty.
Should you also question their competence? They should know, right?
this is less about competence and more about update schedules... we happen to feel like it's worth incorporating guidance that's newer than what HITRUST or our customers require us to (though the guidance in question was updated by NIST eight years ago... sometimes it takes a long time for this stuff to change)
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.
It's also a sort of moral hazard problem.
If you, the person in charge of these decisions, allow an incumbent policy - even a bad one - to stand, then if something goes wrong you can blame the policy. If you change the policy, though, then you're at risk of being held personally responsible if something goes wrong. Even if the change isn't related to the problem.
It's not just cybersecurity. I have a family member who was a medical director, and ran up against it whenever he wanted to update hospital policies and standards of care to reflect new findings. Legal would throw a shitfit about it every time. With the way tort law in the US works, the solution to the trolley problem is always "don't throw the switch" because as soon as you touch it you're involved and can be held responsible for what happens.
I love the analogy to the trolley problem. It sounds like this logic would literally hold up in a real-life trolley problem in regards to the law.
"No-one ever got fired for buying IBM" etc.
I mean that was true about Boeing, right up until it wasn't.
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
Fascinating. In other words:
In order to force the user to change their password more frequently (long term), the user is prevented from changing their password too frequently (short term).
I wonder whether the person who added that is actually confident that the benefits outweigh the drawbacks or is that a case of tunnel vision.
There are also systems that keep a history of old passwords just to prevent you from reusing one.
I like the ones that not only keep a history of your old passwords but will reject any password that is similar to any of your 30 previous passwords, which means they're storing either a plaintext or reversibly encrypted list of every password somewhere on the system. Talk about a goldmine for the hacker that dumps that database.
Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.
This doesn't seem practical at all. The combinatoral explosion would make the storage requirements impractical for everything but the absolutely most trivial cases like incrementing a number as the very last digit. Even in your simple example you're talking about storing 256 different hashes just to catch one possible mutation on a way too short password.
You can store a normalised form -- so if the password is `PaSsWoRd` and the user tries to change it to `pA55wOrD`, a normalisation that lower-cases, turns 1 and i into l, turns 2 and 5 into s, and turns 4 into a, would normalise both to `password`.
Or if you want a slightly more convoluted mechanism, when someone changes their password you have both in plain-text and you can take a copy of the old password at that point -- after all, it's not being used as a password any more! For bonus fun, submit all previous passwords to pwned passwords. Password reuse makes this a bad idea in general, specific policies attempting to mandate it will not be an issue notwithstanding.
Technical/pedantic answer: you can store a 'normalized' hashed form of the password, e.g. before hashing it, convert it to all lowercase, replace all digits with 0, sort the characters, … and then do the same to the new password before hashing it, so a whole bunch of stuff will compare "equal".
Practical/actual answer: this is stupid either way.
You could use a Bloom filter, and just gaslight your users when a false positive happens.
Ye. If the insane password gatekeeper shenanigans doesn't make you input your old password together with the new, you know they store your passwords.
The obvious solution is to have a Monday password, a Tuesday password, etc.
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...
No, you can do it safely. The idea is to have the password renewal process also ask for the previous password.
This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.
Oh so trivially bypassable by changing your password twice.
To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.
No it doesn't. Shows you how complicated all this is and how the un-initiated (including me) should learn to not give their two cents.
When you do the password change it asks you for the old one, that's how it knows.
So it asks for old + new, checks old is correct against the hash, and then compares old + new likeness.
So it all happens in memory.
Unless they ask you for your current password as part of the password change flow.
Is there any way to check that with non-plain-text password?
Actually it can be trivial as long as you can require the user to re-type the current password when entering a new password; check hash first, then check edit distance with the entered "current password" (and, of course, promptly throw it away once you know the edit distance.)
Ohh. I guess that's what Windows does when a user wants to change their own password in the domain.
It does more than that, it keeps a hashed password history (which used to be in the user attr ntPasswdHistory, but is now "somewhere secret" afaik) according to the value of ms-DS-Password-History-Length attribute. OpenLDAP keeps these (ppolicy overlay) in the user object.
So, it can hash any proposed password and compare the history to make it's not been seen $recently (as an exact match, since it's comparing hashes).
It could also perform some minor permutations of any new password, and do the same history check to make sure you're not just changing the first or last character or digit. I don't know if it does this, but it could.
Not if the check is done client-side, so the plain password never leaves you local domain. Of course the check being done client-side means that it isn't difficult to skip if you are inclined to make a smidgin of effort.
It can be done server side too, the old password can be sent along the new one and the server can verify it.
Yes, what I meant to say that it doesn't even have to be done server-side, so the fact it happens doesn't imply the server ever sees the old password beyond it's initial setting.
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.
PCI requires multi-factor auth these days, so you’ll likely find now the ssh password will be your password plus a OTP at the end.
PCI DSS from 4.0 actually have something called customized approach for everything. If you can prove and the QSA agrees that you fullfill the goal of a requirement, you can be quite flexible. Example i am doing things like not using passwords at all and only passkeys, or only ssh keys protected by hardware security key etc. Together with agents trying to verify the devices connected are company owned and hardened in different ways. Your milage might vary depending on how good your auditor is but PCI DSS standard do have quite a bit of flexibility in it.
Presumably at some point in your environment you are doing MFA? Just not at every step?
Ie If someone broke into your office, opened computer, inserted the hardware security key, would they get in? Or is there something else non-physical going on? Like the initial login is password + security key, and you can demonstrate the ssh keys never leave the secured PCs etc.
It is not about MFA or not but to demonstrate the process is secure for the purpose.
It can be complicated but a example. TOTP that is very common used with passwords is regarded as MFA (tho most of the time software based on phone) but have many problems regardless
- many time replayable - can be intercepted - implementations look different - recovery code reuse problems etc.
On the other hand, using only passkeys dont have those problems but with passkeys, many times you cannot decide on what device a user have registrated the passkeys in a enterprise setting. example they could be apple passkeys, chrome passkeys, windows, hardware key(yubikey) etc and all of them behave different when it comes how they ex can be copied/ synced between users devices. So from where they can be used.
So for any authentication flow, you need to look at the full picture. What is the process when credentials are lost? How do user onboard etc.
Is a good entry point to say. We should use MFA or similar but the details matter.
It’s always interesting to hear other people’s approaches- Thanks for the insights!
Isn’t there a way to ask for OTP after initiating the SSH session?
One issue with this is it makes it hard for scripts to log in (this may be what you want)
Yes, via PAM, and this works fine with OpenSSH. But the couple of OTP implementations I've used are the same, you can either provide password and PIN or passwordPIN. In the end they get concatenated, passed to the next layer, and taken apart for checks. This lets it work with brain-dead http basic auth too, if you're unlucky enough to have to use that...
Yeah, I’ve seen it in a couple places, too. (Once I’ve had to write my own wrapper for openfortivpn that did exactly that!)
This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.
But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.
So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.
> But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems.
Though, if someone gets that far, couldn't they also install a key logger on the users system? At that point - whether it's just password or a password enabled SSH key, anything the user does is all compromised regardless.
"Though, if someone gets that far, couldn't they also install a key logger on the users system?"
There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somewhere where someone left a key they shouldn't have. The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held. They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger, depending on how the system is set up and how the user accesses it. These are examples and not even remotely a full enumeration of all the possibilities. I won't tell you which ones, but some of these are things I've personally seen attackers take advantage of, so they're not just theory, either.
When you're under personal attack, not just getting popped by some vuln scanner scanning over the entire Internet, the situation becomes very different than a lot of people here on HN are used to. Ever been locked out of a system accidentally, then thought for a moment and strung together three other things to reach back into the system you were locked out of, like "oh yeah, I can push a software update to this automatic deployment system, which will run a bash script that checks the IP address and if it is this system restarts the ssh server, and so after 10 minutes we should be in"? Imagine someone who does that every day, all the time, as their full time job, and then imagine they're on a team of other people who also do it every day as their full time job, then imagine they've gotten a foothold into your system. Which, by the way, they immediately used to put a command-and-control client on your system, loaded with all kinds of exploits, and the ability to push arbitrary code to any number of systems at a time and all the tooling to use that as if they've been developing it for 20 years, which they have. What's the transitive closure of what they could work out how to access? The answer would probably surprise you.
I appreciate the additional insights, but the premise I'm pushing back on is whenever a SSH key is read, then the user account is by necessity compromised in order to do so. Given that level of a breach, there are myriad ways for an attacker to escalate privilege and exploit their access without worrying about a password on the SSH key. Namely, at that point, cracking the password on the SSH key is a tractable problem.
> They may be using directory traversal from something else to read a key without even necessarily being on the system.
At least on linux - to read the directory containing a SSH key requires the ability to also write to that directory, as the user. Therefore you can also write to '.bashrc' and all sorts of other places. I suspect Windows might have a larger attack surface, but nonetheless, a directory traversal that is able to read and write is also able to install a keylogger.
> They may be on a server somewhere where someone left a key they shouldn't have
Private key should never be transmitted over a network boundary. SSH key passwords can be bruteforced as well. Having a password on the SSH key, when the SSH key is somewhere it really should never have been, is closing the barn door after the horses have left.
> The attacker may have gotten enough of a secret to compromise some other secret store where the key is being held.
Again, getting access to the secret is enough to also have write access and be able to install a key logger. A password on the SSH key still does not help.
> They're probably on a system with user-level access only and that may not be enough to "just" install a keylogger
If a person has enough access to read a SSH key, they can also install a key logger for at least that user account. They are equivalent levels of compromise, a user account having its SSH key read is already compromised.
edit: addendum: There are certainly attacks that can only read the contents of a system, with root that can read the full system. It's just odd to think about, since at that rate the SSH keys being on a prod system is already such a big no-no. SSH keys really need to live exactly just on the personal devices of the people who own those keys - EG: it should never be the case that say a SQL injection attack that gains root level read permission over everything on a filesystem can then ever read SSH keys - cause those keys should never be on the remote system to begin with. Putting a password on private keys that are then copied to servers _is_ security theater; the keys ought to never be copied to a remote server to begin with.
I can tell you've not been involved in defending against an active attack. You, as the defender, do not get to play the game of "well, if I squint and read it that way, that attack wouldn't work". The attackers get to play "well, hey, if it turns out I do this and that and push it through the other thing, I get access". They are the ones who get to flow through any crack they can find. They are the ones who get to do logic chopping like you're trying to do. You don't get to argue "Well gosh, that team shouldn't have left that one permission open on that one system, that's not a best practice, if they'd followed best practices 100% of the time the attackers couldn't have gotten in...". Your job is to pick up the pieces.
> I can tell you've not been involved in defending against an active attack.
Um... I'm really happy you can mind read dude.
The whole premise here is whether passwords on SSH keys actually help.
SSH keys tend to live in two places: (1) a developers laptop, (2) some sort of CI/CD machine.
The passworded SSH key helps in case (1) only when a person walks away from the laptop and leaves it unlocked. An attacker can't simply then open up a SSH terminal and then SSH to whatever they see in the history. Or, it helps in case a person has a laptop that never locks and the org is simply trying to buy enough time to rotate the persons public keys before the SSH key password is cracked. The SSH key password can buy time, yes - but it does not change the actual security posture.
In case (2), all sorts of considerations need to be made. Though, any password would need to be encoded in a way that is just as accessible as the secret key itself. In case (2), the password really does nothing.
So, yeah, passwording a SSH key does not really help very much. If the keys are left around, then it is the fact they are left around that is a problem. The solution is not to create a scanner that all SSH keys have a password on them, but instead be sure that no SSH keys are installed on systems where they do not belong.
> They are the ones who get to flow through any crack they can find.
I would agree, that is why defense in depth is a good principle just as zero trust security.
So.. passworded SSH keys are kinda really security theater. Please give an attack vector on a persons laptop where the password SSH key is going to stop an attack that is otherwise unachievable. I'll steel man the counter position and mention that physical access is one case (except in that case we are only buying time). AFAIK, that is really it, that is the one place where a password on a SSH key helps.
To hack a persons laptop and read contents in the .ssh directory is a full compromise. To pick up the pieces after that, you need to do things like make sure the compromise can be observed, that privilege escalation is limited. If it comes down to the password on a SSH key being last line of defense - it's game over.
Keep in mind, your burden of proof is to show cases where SSH password actually provides a true increase in real security. The meta conversation of "well, you obviously never have.." is not interesting.
I'll note, if it is the case that SSH passwords are actual security - then, presumably you would feel comfortable stating "yeah, the SSH key was stolen, but nothing needs to be done because the SSH key had a password on it!" It's like the locks on doors, it is for the honest people, the criminals are only slowed down but not stopped by most door locks.
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.
When I first set up an account at a new org or whatever, I don't think about the possibility of rotation later, but once I get my first "your password has expired and needs to be reset" message, I just add a counter to the end of the password that I increment each time I'm required to change it. Successive passwords have no less entropy than the original password, anyway.
Fortunately, I haven't encountered a system that does a similarity check when changing the password.
> 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.
This can be done at login time without the user noticing, as you have the plaintext password for a moment.
Yeah, this is the best practice. We offer that in our product.
But it's possible that you could follow the best practice and still force a reset. This could be because:
* the customer or provider doesn't want to wait for everyone to log in
* they've waited for N months and now there is a block of users who have not logged in yet and they think it is worth the user annoyance to just force them all to reset their password
They could do that by comparing against the old hash and if it matches generate the new hash to store somewhere.
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-...
> If the password length is 12 to 15 characters, it will be valid for 180 days
> If the password length is 16 to 32 characters, it will be valid for 365 days
Madness.
I'm a big fan of "should not include profanity, words of a vulgar nature". It's not unthinkable my password manager comes up with a chain of letters that at one point will include "fuck".
> I'm a big fan of "should not include profanity, words of a vulgar nature".
On my first Wireguard testbed, WG's keygen dropped one at the front of the key. It remains my most treasured digital possession.
This comment reminded me of a talk I saw[1] about Apple's password generation algorithm. Apparently (and unsurprisingly), they have a list of offensive terms the system is designed to avoid. I expect this is common-enough practice in most popular password managers, but probably not all.
[1] https://www.youtube.com/watch?v=-0dwX2kf6Oc
Now I'm trying to remember where I read the story about somebody who was in a programming class and was writing some program that took user input, and figured that it should be smart enough not to repeat curse words. So they started writing down all the curse words it should know not to say, and that was about the extent of what they had done when the teacher came around to see how everything was going.
It would be fun to make a passphrase generator that always includes a profanity.
So long as they factor that into the "bits of entropy" calculation.
Dibs for calling it misenthropy. Entropy mixed with misantrophy.
Word list based passphrases mostly avoid this, by not including those words. Which still doesn't mean you won't get something offensive, of course, it'll just be a string of four words instead of four letters.
It kinda is good personal policy IMO for passwords you have to type to be positive affirmations. I used 'Fuckthis1!' for a moment; funny enough it was not the most moralizing thing to type all the time! OTOH, 'H@ppyH@ppyJoyJoy!!' was always a small mood lift.
What's the scope of that? Not consumer accounts I imagine? I haven't had to change my bank account passwords in over a decade.
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.
>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.
if it causes 90% of people to just enter a simpler password, out of frustration and “fatigue”, then this is irrelevant IMO. Theory doesn’t take into account human behavior.
It’s especially annoying when a company enforces these brain dead policies on employees. You want people to waste mental effort changing their passwords by 1 letter every 3 months, just to appease some IT manager? Give me a break lol.
I’d rather have a long complex password that i remember and remember ONCE.
That's what baffles me. Somehow security NEVER acknowledges that security theater, cognitive overload and constant friction makes users more inclined to make bad decisions, repetition over months make this even worse.
Hackers need just one chain of tired persons to breach a system. Sometimes length(chain) = 1, that's when bad things happen.
Anecdotal PS: I used to work at a bank and had to rotate my password monthly (sometimes even more, because there were unfederated systems that required another password, also with rotation). Eventually all my passwords became [short STRING] + [autoincremental INT]. We had MFA, so it didn't matter that much, but that makes it even more hilarious.
I think directly caused by the fact that at large companies, the best way to get ahead is to be seen as doing things. It doesn't matter if those things are completely harmful, so long as they sound good. With password changes you now have company wide visibility, with regularity, doing something that to somebody who's not thinking much would probably be suggestive of doing a very thorough job.
For most people, writing (most of) their password on a piece of paper that they keep in their wallet would be pretty good security.
Paper can't be hacked, and writing down the password allows for more complicated passwords. In case someone gets access to your wallet, you still keep a portion of the password not written down.
(And if someone gets physical access to your stuff, you are hosed in general, because they can just install a keylogger. So even keeping your password fragment on a post-it under your keyboard would be fine-ish.)
It really depends on what password. At home our wifi password is on a paper, right there on the office board. If you landed in the room, I won't feel more in security if you need other actions to get the password out of me.
> At home our wifi password is on a paper, right there on the office board.
You probably should know that recent smartphones (the most likely devices to ask for a wifi password at home) have features to share a password right in the settings. iPhones will simply ask you (or anyone connected) to allow them, and androids have some sort of sharing enabled (via qr code generally).
No, like I don’t believe the math. It’s not about not wanting to believe the math. I don’t believe the mathematical conclusion is practically true even if there may be something theoretically interesting to talk about, like the monty hall problem.
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?
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.
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
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.
That's why we recommend passphrases. That 30 character requirement becomes much easier when it's 3-4 words with a separater. Faster to type, too.
Which does nothing for the "stupid people". I.e. the ones that we put these rules into place for. They'll do what I posted instead (or something else easily guessable and the cycle continues - technological solution to a people problem, i.e. doesn't work)
I would hate to be labeled 'stupid' everytime I don't want to type some 30 dumb characters everytime I login. How about no?
Different difference ;)
I also don't want to type 30 chars, when 15 _properly randomly chosen_ characters would suffice but the "stupid people" chose those 15 characters as "passwordP@55w0rd" and now everyone requires us to write 30 instead because it's "so much more secure" when they write "passwordP@55w0rdpasswordP@55w0rd"
You're all missing the point.
There are different attack vectors. Yes, 15 random chars is sufficient if random, but recalling and typing 15 truly random characters is a big challenge for most everyone.
You shouldn't be having to remember and type your password for Hacker News, for Gmail, or your bank, ever, not even one time.
By making them 30 characters, you're ensuring one of two things:
A. Users at least use a passphrase such as "my dad liked to drink 6 packs of Miller Lite" which is brute-force-proof so, that's fine
B. Users who aren't masochists use a password manager properly and never have to even see their password let alone type it.
That's it, that's the whole endgame. By keeping passwords short enough to memorize and type, you're just enabling people to use P455w0rd. And if you think that only impacts stupid people, most people are stupid and many of them are in charge of keeping your data (and infrastructure, and government, etc) safe. You need them to be protected, to protect you.
I don't think that is correct at all.
Users are not "at least using a passphrase". They will do the simplest thing ever.
What happened when people used the password "123" and we added "Must have at least 8 chars"? They make it "password".
What happened when people used the password "password" and we added "Must have one upper case char"? They make it "Password" or "passworD".
What happened when people used the password "Password" and we added "Must have one number"? They make it "Password1".
What happened when people used the password "Password1" and we added "Must have one special char"? They make it "Password1!".
Guess what happened when people used the password "Password1!" and we added "Must be 30 chars long"? They make it "Password901234567890123456789!".
(or anything else stupidly easy based on whatever password they used to have anyway)
As in, you are missing the point I'm making. You cannot solve a people education problem by adding more and more "stringent" requirements. You need to educate them. You need to make them understand why it matters. Only then might they actually care enough to use a proper passphrase like you suggested.
In that sense I do agree with you that using a password manager is the best most people can do. I use one at work and it's a game changer. But I only use it, because it's provided by work and thus it's free for me. If they didn't provide it, guess what I would do too? If they have obnoxious rules, then I will thwart them any which way makes it easier for me. So my "change your password every 30 days and it can't be one of the last 8" password of course was my last password but it went up to <lastPassword>8 until I went to <lastPassword> again.
Correct-horse-battery-staple!! is 30 characters and quick to type
Which does nothing for the "stupid people". I.e. the ones that we put these rules into place for. They'll do what I posted instead (or something else easily guessable and the cycle continues - technological solution to a people problem, i.e. doesn't work)
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.
And require smart card, reader, drivers etc... nah
Every work laptop I've used had a smart card reader directly built into it and I've never used smart cards.
Or a yubikey, or a webcam, or a fingerprint sensor…
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.
Also don't allow them to copy paste the password. And especially don't allow them to use any kind of password wallet. They will really love you for this and you won't get an excessive number of calls to reset forgotten/lost passwords.
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.
I think if done right, typing that password should be more like a once a quarter exception rather than a daily occurrence.
Granted - there are blockers to getting there. IDK why for example, macOS can't use Touch ID from a cold boot, that's stupid, at least when there haven't been too many failed attempts or anything.
> macOS can't use Touch ID from a cold boot
Isn't that because the Secure Enclave (the only place which contains the Touch ID biometric data) is locked by your password?
"When a user's password is set up on an Apple Silicon Mac, the password is passed through a one-way hashing algorithm that produces a key used to encrypt the Secure enclave's key."[0]
[0] https://blog.greggant.com/posts/2023/04/14/the-security-encl...
Touch ID isn’t that secure. It’s fine for personal devices, but I wouldn’t trust it alone in a government or cooperate environment.
A ~1:50,000 error rate per finger added sounds fine, but lose a few laptops and have multiple valid fingerprints etc and the odds quickly look significantly worse. Or a janitor could end up trying to log into a significant number of machines etc.
You're only supposed to type your password at most once a day to sign into SSO.
Then how do you suggest authenticating not just in the morning but after lunch, going to the bathroom, any physical meetings, etc?
"Your password is too similar to your previous password"
Hmm, how would you know that.
Don't you generally have to enter the current password to change it to a new one?
Interesting. I guess you could do it on the frontend by asking for old and new passwords simultaneously and sending the hashes to the backend.
That said, it means that you can skip this check by hacking around the front end check haha
By making it less secure. Like those auth schemes back in the day that sounded great in theory until you figured out that in order to implement them the provider had to store them un-hashed. No thanks.
Hash each character.
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?
In practice, that's probably how it's done. But in theory: no.
Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash.
By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want.
If you only care about similarity to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.
Wouldn't this be super slow if you're using a proper password hashing algorithm?
Yes, if it takes one cpu second to hash a password, it'll take a while to try a few like this.
You can do a quick check against the last password (which you have in clear, because it was just entered), though.
Not if they ask for the current password at the same time.
https://news.ycombinator.com/item?id=44265372
Similarly of new vs current password is simple enough by just requiring the current password as part of the password change call. Which is a good idea anyway so someone can't just walk up and change your password if you forget to lock things over lunch.
Similarly vs older passwords is what would be an issue.
> Similarly vs older passwords is what would be an issue.
Which isn't unheard of, though it's been years since I've seen it.
It probably requires some sort of decreased security (if the password hash is truly slow & secure, it would be hard to enforce dissimilarity); but there might be other methods that leak less than cleartext (like salting and storing hashes of overlapping/separate n-grams from the previous password and checking for number of similar n-grams; etc). Or as another commenter suggested checking all passwords within edit distance 1 (though if you can do that, your password hashing algorithm is likely too fast).
Interesting perspective. Wonder why so many SaaS service currently enforce this.
Cargo culting.
> 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.