←back to thread

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

(www.bastionzero.com)
656 points EthanHeilman | 1 comments | 27 Jan 22 15:06 UTC | HN request time: 0s | source
Show context
staticassertion ◴[27 Jan 22 15:56 UTC] No.30102061[source]▶
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 edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
c0l0 ◴[27 Jan 22 18:23 UTC] No.30104121[source]▶
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.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

replies(16): >>30104148 #>>30104166 #>>30104241 #>>30104603 #>>30105136 #>>30106352 #>>30106792 #>>30107048 #>>30107250 #>>30107515 #>>30108070 #>>30108409 #>>30108716 #>>30108754 #>>30109550 #>>30123243 #
Signez ◴[27 Jan 22 18:26 UTC] No.30104166[source]▶
Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement.

Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."

replies(4): >>30104681 #>>30107064 #>>30107180 #>>30108251 #
hansvm ◴[27 Jan 22 21:45 UTC] No.30107180[source]▶
Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.
replies(3): >>30107937 #>>30108092 #>>30108533 #
dpatterbee ◴[27 Jan 22 22:46 UTC] No.30108092{3}[source]▶
I feel like the issue with the post you mention was the absence of recourse rather than the locking out itself.
replies(2): >>30109070 #>>30129759 #
1. hansvm ◴[29 Jan 22 19:52 UTC] No.30129759{4}[source]▶
That definitely exacerbates the issue, but I don't think it's fair to claim that the absence of recourse is the _only_ problem. If you have limited cell service, limited connectivity, or limited time, then the account being locked can be a significant burden that completely blocks whatever opportunity you were trying to take advantage of. Note that the response time even for newsworthy account locking events is still on the order of hours to days.