Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I read the federal government’s Zero-Trust Memo so you don’t have to

bastionzero.com

Post reply on HN
Print view View original

211–220 of 369 posts

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#211

Post by wslack »

gkop wrote: post #121
mooreds wrote: post #108

Earlier quoted context omitted.

To be fair, this was part of the NIST guidelines since Mar 2020. A whole appendix was added to justify it: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

Way earlier than that, even. > Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too. https://web.archive.org/web/20160624033024/https://pages.nis...

They accepted edits via pull request when that was in the works! [1] Such a better model of giving feedback or suggesting edits compared to sending in a marked-up PDF.

[1]: https://github.com/usnistgov/800-63-3/pull/576

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#212

Post by 0xedd »

no_time wrote: post #163
c0l0 wrote: post #31

Earlier quoted context omitted.

I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…

>Remote attestation really is killing practical software freedom. Which will continue marching forward without pro-user legislation. Which is extraordinarly unlikely to happen since the government has vested interest in this development.

*in the US.

Luckily, it's a dwindling power and Europe fights and penalizes large organizations breaching market "morals".

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#213

Post by cryptica »

I thought we had reached peak bureaucracy but I was wrong.

On the plus side, it's good that they finally figured out that forcing frequent password changes and forcing the usage of special characters are anti-patterns. I've been repeating this for over a decade.

Deprecating passwords is the wrong conclusion. A better solution would be to educate people about good password creation and handling practices. A 1-page document and/or short video would do.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#214

Post by themacguffinman »

0xedd wrote: post #210
alksjdalkj wrote: post #129

Earlier quoted context omitted.

Totally locking down a computer to just a pre-approved set of software is a huge step towards securing it from the kind of attackers most individuals, companies, and governments are concerned with. Sacrificing "software freedom" for that kind of security is a trade off that the vast majority of users will be willing to make - and I think the free software community will need to come to terms with that fact at some po…

Wrong. 80% of attacks are social engineering ones. In which an employee is convinced to make a bank transfer, open some document, install some program. From there, often times it's exploiting wide spread software commonly found in large organizations. Everything you said cannot be further from the truth.

Hence the pre-approved software restrictions. In a locked down system, even the most gullible employee won't have the authorization to "install some program".

I'd also hope that businesses care about more than 80% of attacks, preferably they should care about 100% of attacks. Hence, pre-approved software restrictions.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#215

Post by godelski »

pm90 wrote: post #48
CGamesPlay wrote: post #40

Earlier quoted context omitted.

I am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?

If we were to stop using special characters and only use human friendly phrases (eg “jupiterIsTheSmallestPlanet”) it wouldn’t be the end of the world.

But if a whitespace is not a special character (or punctuation) we can add entropy with "Jupiter is the smallest planet!" while still being human readable and using the passphrase paradigm.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#216

Post by mschuster91 »

shbooms wrote: post #101
tablespoon wrote: post #81

Earlier quoted context omitted.

>> 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. > I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaning…

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

> But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing.

And this has happened before, with Intel ME that was and still is useful if you have a fleet of servers to manage but a hell of a security hole outside of corporate world.

And now that Windows 11 all but requires a working TPM to install (although there are ways to bypass it for now), I would not be surprised if Netflix and the rest of the content MAFIAA would follow their Android approach and demand that the user have Secure Boot enabled, only Microsoft-certified kernel drivers loaded and the decryption running in an OS-secured sandbox that even a Local Administrator-level account can access.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#217

Post by tialaramex »

withinboredom wrote: post #195
codemac wrote: post #127

Earlier quoted context omitted.

Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.

I prefer to keep my email as dumbly secured as possible. I’ll never forget this one time I was on my sailboat with no cell service and only an open WiFi connection from shore. I couldn’t login to anything via sms auth. Same thing with FIDO keys when traveling. Lost luggage? No logging in for you until you get home to get your backup? Cut your finger while cooking? No logging in for you! Have to wear a face mask? No l…

So, I'm somebody who thinks about contingencies a lot and to my mind, there's just not a lot of gap between situations where you don't need credentials (e.g. satellite beacons don't care who you are) and where you don't have credentials (oh no, I lost all the gear) so it doesn't represent a big worry for me.

I don't want the consular officials to be unable to authenticate me in a foreign country because I lost my phone, or for my bank to be unable to release funds because I don't have their card or my Security Key, but I feel 100% OK with losing access to Gmail or Hacker News, or whatever for say a few days until I can secure replacement credentials.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#218

Post by count »

Godel_unicode wrote: post #158
count wrote: post #134

Earlier quoted context omitted.

PIV/CAC Smartcards.

That's an interesting subject, since there has been a lot of government push for PIV but the internet has essentially decided that FIDO2/webauthn are the way forward and making them work with PIV is non-trivial.

Agreed. Strong authentication vs. strong identity proofing.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#219

Post by tialaramex »

dmd wrote: post #206
YeBanKo wrote: post #147

Earlier quoted context omitted.

I have an issue with using ID.me for government websites, because it is a privately owned company. Online authentication at this point seems as important as USPS service and warrants being owned and developed by the government itself.

They even HAVE this already, at https://login.gov/ !

I have a login.gov account. Needless to say I'm not a US citizen, and the IRS should not cut me a refund check.

ID.me supports WebAuthn (or maybe U2F? In this context it doesn't matter) but importantly it does identity verification so it can determine whether I am a US citizen, whether I'm a tax payer, and if so which one.

Now, perhaps the US Federal Government should own the capability to do that instead of a private company. But, so far as I can tell, they do not and login.gov is not such a thing.

Re: I read the federal government’s Zero-Trust Memo so you don’t have to

#220

Post by staticassertion »

c0l0 wrote: post #31
staticassertion wrote: post #2

This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices. 1. No more SMS and TOTP. FIDO2 tokens only. 2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible. 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edg…

I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…

I wish I had responded earlier, because now this entire thread is full of nonsense and I can't really respond to everything.

But attestation can mean a lot of things and isn't inherently in conflict with free software. For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Free software would only, in theory, need a digital signature so that we could add that to our allowlist.

Post reply on HN