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.

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

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.

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.

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

For what it's worth NIST password guidance SP800-63b no longer advises the arbitrary expiration, so hopefully this is something that will change.

>“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

NIST changed those rules a few years ago, I think. I remember thinking "please, PLEASE let companies follow suit...".

And still, very few have :(

I think it's new as of the 2019 revision, though it wouldn't surprise me if it's been ignored for a while. I don't think CMMC requirements specifically call out expiration periods, so hopefully a good sign.

Microsoft seems to be fairly forward thinking[1] on passwords, doing away with expiration requirements and focusing more on their risk based MFA stuff.

[1]https://www.microsoft.com/en-us/research/wp-content/uploads/...

PCI/DSS hasn't yet, so that's holding up a lot of them.

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.

Has this shown up everywhere. Govt agencies still had it in contract docs. That might mean fedramp or PCI or some other standard still mandates it.

Enforces minimum password complexity of case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type; Enforces at least 5 changed characters when new passwords are created: Stores and transmits only cryptographically-protected passwords; Enforces password minimum and maximum lifetime restrictions of 60 days; Prohibits password reuse for 10 generations ...

Incompetence runs through every facet of American government, corporations and even private businesses. There's an insane amount of bureaucracy and people doing IT who have no business doing IT. As for the corporations, the established ones get taken over by the MBA types who have no clue about software or security nor do they care as long as the numbers look good for the next quarter.

I'd bet dollars to donuts that firms run by professional managers almost certainly have better security practices than family or founder run firms. I say this because research shows that professionally managed firms excel in virtually every other facet of operations and management[1].

[1] https://hbr.org/2011/03/family-firms-need-professional

Although I do not disagree with your comment, I would do a double take befpre accepting the source you cite because they are very much incentived to proclaim the result they proclaim.

MBAs discover companies desperately need MBAs!

you mean professionally run corporations like Equifax, Target or SolarWinds (published ftp password to github)?

Professionally managed versus family managed. Not surprising, both are not quite related to the technical matter being discussed.

Muskets beat bows and arrows, but we're in the 21st century now.

Neither of these hacks involved "back doors" as they are normally defined. One was an authentication bypass; the other was a supply chain attack. Neither involved any sort of deliberate covert access mechanism.

I don't think OP meant to imply that backdoors had anything to do with this. It's meant to underscore the argument against backdooring encryption by pointing out that when you trust some entity with a backdoor, you're potentially opening that backdoor to anyone who can break that entity's security, which may be very, very flawed.

That's unrelated to backdoors (deliberate covert access mechanisms). All parties with access to data, regardless of whether it is via a backdoor, can put that data at risk due to their own security.

This is only unrelated if you don't consider government-mandated master key escrow a "backdoor," which seems deliberately obtuse to me. Regardless, the OP's point was that this is an additional argument against governments mandating a way to access your encrypted data, because you shouldn't be compelled to trust anyone else with a "don't worry, only we will have access" sort of system.

Let me be cystal clear. I've worked in domestic violence. Cops will use various tools to stalk their ex'es despite your claims that back door or priveleged access will not be abused.

Jump over to healthcare, the worker with full access to the govt it system for cases WILL lookup their friend / family members / neighbors / famous person if they see them on site or realize they are in system.

I have one experience with a private health HMO. A close relative, senior doctor, absolutely knew they would be immediately fired if they looked up family records. It was crazy, they would not do ANYTHING related to family stuff even by request of person involved. Obviously this place had some type of audit trail, some type of monitoring team for non-assigned patient record lookups etc.

My govt IT job, to do billing you had to be able to see case notes, and the system was integrated across of a ton of agencies, so everyone basically had access to everything and because you had to share logins and passwords (it took like 6 months to get a new account setup) there wasn't any accountability (not that I think they monitored anyway).

I came away very unimpressed. We had to use outdated IE / Java combos etc. as well and block all system updates. The default landing page was an unregistered domain name.

US gov guidance from NIST no longer suggests regular password resets, but that guidance hasn't gotten out yet.

> 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). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Source: https://pages.nist.gov/800-63-3/sp800-63b.html

I hated this part of being on-call for government customers. I had to go through some crazy adjudication process all for the privilege of having to change my passwords every 60 days. And even though I used a password manager for them I couldn't paste them in because the VM I was required to use to access the systems didn't allow pasting from the outside.

So I just typed them into notes on the VM and left them there.

>> In lots of documents that float around, emailed around etc etc.

The amount of fortune 500 and fortune 100 companies that I worked at where this is commonplace is staggering. The amount of businesses that never change their passwords is quite frankly, shocking. I left a fortune 500 company two years ago and I just tried my login on their external facing portal - and it still worked.

I've seen passwords being passed around in word docs and internal blog posts. At one place they were mixing development information with financial information. The idea you had several folders of corporate contracts mingling with developer docs on a sharepoint server was a real eye opener for me.

Nobody else seemed to care when I brought up the fact you just gave a bunch of developers access to facebook contracts and other financially important docs they have no reason to have access to. Their reason? It was too hard to set up a new folder with access restricted.

After a few years of experiencing these, I just became kind of apathetic to it. If nobody in authority cares, then why should I??

You should check out the new CMMC requirements -- basically a new set of basic cyber security requirements for all DoD suppliers, starting next year.

It's heavily based on the NIST guidelines, so strong on 2FA, and discourages arbitrary password rotation.

Spot on, humans are always the weakest link. You must assume your users will invoke every worst practice imaginable and make your system secure anyway.

Aside from anything else, your second point is exactly spot-on. That's not just your impression.

> With google I've had one password for 20 years (my google account) which allows a hardware key for 2FA or google authenticator with what I imagine is sensible monitoring, new device authentication etc (I find this pretty secure).

I too hope this is not just security theater as well.