Hacker News Reader

Comment by Jtsummers | Hacker News Reader

The insistence on the stupidly long passwords and 30-60 day expiration times created so many weaknesses. People choose obvious patterns for their passwords to get around it. Like `1q2w3e4r!Q@W#E$R`. Then they shift by one each time they have to update, by the time they get across the keyboard they can restart (or twice, in which case you swap the shift to the first half instead of second half). Or, this was fun, my first gov't job the guy had stored passwords on a sticky underneath the keyboard (I changed them all). They also used a shared account for admin stuffs, even though we were all given an admin token (like the smart card or CAC for regular login, but with admin credentials and issued separately).

In theory, the DOD CAC system (they've gotten better over the years) eliminates the need for passwords entirely, but somehow most teams never tie their system to it properly.

View on HN

NIST no longer suggests such a rotation policy. They have accepted that it weakens security.

Anecdotally, colleagues have successfully lobbied to drop (or not enforce) password expiration policies from other government bodies on the strength of this recommendation from NIST.

Yeah, I know it's not actually recommended anymore, but the policy makers don't care. They're doing CYA policy. They do whatever seems to be the strongest possible thing, users and reality be damned.

I was in a team whose security group eliminated the use of DVD drives for reading (not writing) data except for a few permitted individuals. Creating a massive chokepoint in every process where data had to come from off-network. Security didn't care, it took the realization of the cost (delays, people too busy moving data to do their actual jobs) for management to step in and end the nonsense.

The same will be required for things like password policies. Until the issue becomes realized (weak/written passwords lead to a compromise), these policies will stay in place within organizations and teams. It doesn't help that the majority of the policy setters are not IT professionals (or only in the loosest sense, they can install software but have no real understanding of IT systems). In DoD, most come from a physical security background (retired/separated security forces).

> They do whatever seems to be the strongest possible thing

It's not that, it's inertia and poor incentive structures.

In a large organization, if a policy was set in place by someone else, then, even when you know it's a sub-par policy, it's still in your interest to leave it alone. Doing so gives you a way to deflect blame in the event of a breach related to that decision. You can just blame the policy itself. If, on the other hand, you change the policy, you're more likely to be held personally accountable.

That said, you're also absolutely right about the expertise problem. I don't know much about government, but, in private industry, I've observed that the best way to get put in charge of cybersecurity is to start from somewhere completely outside of IT, and become good friends with the CEO.

> It's not that, it's inertia and poor incentive structures.

This is the psychological/economics point of view, and I think it's the correct one for this problem. The other tricky issue, besides the CYA prioritization, is that being a dynamic entity requires other entities to do the same. If you start changing procedures in your section, other sections that rely on you need to adapt to these, and they may have the CYA attitude and resist that change.

It's certainly possible that in some cases that's true, but there are a lot of government check-box security people who genuinely believe complex passwords rotated frequently are a good security control. There's also a general heuristic with many people in security that the more convenient something is, the less secure it is. Therefore smart card auth must be worse!

Citation? I couldn't find anything on the web or here: https://pages.nist.gov/800-63-3/sp800-63b.html

edit: I wasn't calling OP a liar, I just couldn't find it.

It's right there in section 5.1.1.2:

"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

Harmj0y, who is probably the best public AD hacker right now suggests 3 month rotations, IIRC.

My guess is the idea is to mitigate compromise of very old passwords, spray attacks using breached site creds, reduce insider threat and at least offer some mitigation for compromised hashes.

I think this is wise compared in work environments - 90 days, 180 or even 360 would be a good mitigation over _none_ to too many.

I think those concerns are better addressed elsewhere with tools like MFA, automatically disabling inactive accounts, or monitoring public services like HIBP to deactivate accounts quickly. Attackers can move quickly so you hit diminishing returns on rotation policies trying to avoid usability issues incentivizing worse passwords while not rotating long after the account has been compromised.

Oh! Please tell me how you implement MFA on AD domains!

Azure AD/Azure AD hybrid might be worth a look

Should be noted that NIST’s current recommendations are meant to be part of a number of mitigation’s including checking passwords against known-breach databases, rate-limiting, etc.

Without those other mitigations, pw rotation may still help more than it hinders, although I am definitely not a fan of it and recommend implementing all of the NIST’s recs instead.

For those looking to head that route, haveibeenpwned offers an API to check hashes against previous breaches. For a pw strength meter, have a look at zxcvbn.

However I'm pretty sure PCIDSS does still say 90 days

all the more reason to prioritize minimization of scope for PCI ;)

You are allowed to use the NIST Guidance as a reason to change that to a longer timeframe. I have a couple of clients that are using 365days as of 2019.

PCIDSS is largely security theater as well, there are many many many problems with it.

Yes, but as far as I have seen, not auditing/compliance frameworks have updated their recommendations yet. Maybe its not the frameworks, but the individual auditors and their templates, but I have seen it a 'requirement' for PCI, sarbenes-oakly, etc.

its much easier to keep it in place to make the auditors happy than remove it, and risk exceptions on your report that you have to defend.

None the less, until the pandemic hit the US in March, at least one large government agency still had silly password complexity requirements and expired passwords every 60 days. They seems to have suspended password rotation at some point since I haven't had to change my password since March, but it's not clear whether it's going to come back at some point or not.

IRS still requires stupid complexity and lockouts in the beloved pub 1075.

Indeed. Sports Team + Year, Season + Year, Company + Year or some other such combination should get you a good 10% or more of your users with only a few dozen permutations.

They wrote 60 days into FEDRAMP I believe, something I jaw-droppingly realized last year sometime. Whoever is writing these policy frames don't know what they're doing. NIST did away with those periodic password change recommendations for a very good reason but IMO they need to now recommend the opposite, directly, because the constant password changes are doing real harm.

According to another comment, they do:

> It's right there in section 5.1.1.2: "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

https://news.ycombinator.com/item?id=25421584

Yeah I always use something + year + month + day, otherwise how am I supposed to get it around...

>Or, this was fun, my first gov't job the guy had stored passwords on a sticky underneath the keyboard (I changed them all).

Nothing wrong with writing passwords down. Or at least it's the least wrong thing you could do among all things mentioned here.

It depends entirely on your security and threat model. Me, working from home? I'll write down the password for my netflix account and wifi - sure.

In an office? Absolutely not, never, not once. Offices are not private and not secure and in any kind of even vaguely sensitive setting allowing a colleague to have access to your password and impersonate you is a massive risk.

Yeah, it really depends - in many cases an attacker gaining local access is game over anyway & less technical users will at least have harder to guess passwords. In other cases it's indeed a bad idea.

I would partially agree with this. It's not wrong to write down passwords. It is wrong to write them down and not secure them. Securing them is the same step that happens (or is intended to happen) with password managers. The passwords are, themselves, encrypted in some fashion so that they're not (easily) accessible to others. If these passwords were at least put in a locked cabinet, I'd have felt better about it. A safe would've been even better (and this is assuming that they needed to be shared, we had security tokens that, if used properly, meant we didn't need the passwords at all and each person would have a unique access token for better accountability).

It is moronic to write passwords down and stick them underneath the keyboard.

I wonder if they use password managers. All the household-name corporations and small startups alike where I worked for the last decade used a password manager.

Selling a subscription to a government org should look like a tasty enough piece of revenue pie to attract multiple bidders, I assume.

how do you manage passwords at such a scale though? where do you keep the password DB?

What’s preventing more rapid uptake of integrating with the CAC system? I can use my CAC when going through TSA for ID (and verification is sub 10 seconds) but other agencies keep dragging their feet.

It seems to be laziness on the part of the IT system makers. There are (mostly) standardized ways to authenticate a CAC and associate it with a user for an information system. But people seem to prefer to roll their own. Either using traditional username/password combos, or a worse solution.

The worse one is this (seen a few times): Username/password and then you register your CAC with it. They only check the CAC itself for the cert expiration date. When it does finally expire (or gets revoked, say you need a new one early like happened to me a couple times, not to loss just became unreliable in the CAC reader), then you have to use the username/password combo (the password has been getting updated every 60-90 days during all this time) and register your new CAC.

But, since they aren't checking revocation data a stolen CAC + PIN (say it's weak, beaten out of you, or they observe you using it) even revoked would still be able to authenticate against that system until the cert expires or the admin (usually) manually removes the revoked CAC.

As an IAM/trust systems enthusiast with a passing interest in the CAC system (and tangentially, Login.gov), this is disappointing to hear. Thanks for the context. I’ll keep my eye out for opportunities to contribute to improving the situation (USDS or 18F).

Happy CAC user here. I would love to see them as common as driver's licenses. Maybe then we could do away with SSNs as a secret identifier.

That’s the end goal, adopting a system similar to Estonia’s national ID infrastructure.

Reply on news.ycombinator.com