Comment by montebicyclelo

It absolutely was/is.

To bastardize Douglas Adams: For-profit insurance is a scam; breach insurance, doubly-so.

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.

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)

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.

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.

The obvious solution is to have a Monday password, a Tuesday password, etc.

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.

To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.

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.

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.

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.

This can be done at login time without the user noticing, as you have the plaintext password for a moment.

They could do that by comparing against the old hash and if it matches generate the new hash to store somewhere.

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

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.

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.

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.

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.

Correct-horse-battery-staple!! is 30 characters and quick to type

And require smart card, reader, drivers etc... nah

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.

Don't you generally have to enter the current password to change it to a new one?

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.

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.

You're only supposed to type your password at most once a day to sign into SSO.

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.

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.

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.