Live data from Hacker News

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

bastionzero.com

111–120 of 369 posts

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

#111
post #80

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum tra…

Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.

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

#112
post #91

Earlier quoted context omitted.

No, I'd expect it does include TOTP. Read it as "discontinue support for protocols that supply one-time codes". A TOTP app would fall under that description. TOTP apps are certainly better than getting codes via SMS, but they're still susceptible to phishing. The normal attack there is that the attacker (who has already figured out your password) signs into your bank account, gets the MFA prompt, and then sends an SM…

All of this is really government we-don't-pick-winners speak for yubikeys.

My OpenSK chip begs to differ. https://github.com/google/OpenSK

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

#113
TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life.

TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker.

The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general best practices guide. It is a valid best practice guide for a particular use case and particular user base.

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

#114

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The sam…

The terminology stems from "zero trusting" the network you're in - just because someone can talk to a system doesn't mean they should be able to do anything; the user (via their user agent) should be forced to prove who they say they are before you trust them and before anything can be carried out.

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

#115
post #56
post #24

> Do not give long-lived credentials to your users. This screams "we'll use more post-it notes for our passwords compared to before", or maybe the real world to which this memo is addressed is different compared to the real (work-related) world I know.

The general attitude among practitioners now is that "post-it notes with passwords on them" is superior to the more common practice of "shitty passwords shared across multiple services".

Back in 2009 or so I stored my most-frequently used psswords on a piece of paper in my wallet.

(These days I simply use 1Password.)

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

#116
post #38

The real crux of the issue is the long-tail of applications which were never conceived with anything but network-based trust. I'm certain the DoD is absolutely packed with these, probably for nearly every workflow. The reason this was so "easy" for Google (and some other companies, like GitLab[1]) to realize most of these goals is that they are a web-based technology company - fundamentally the tooling and scalable s…

As if Gov't does their own IT infrastrucutre... This is a windfall for Gov't contractors.

Hey, at least they're 'our kind' of Gov't contractors. No $640 toilet seats here ;)

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

#117

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

$ host buganizer.corp.google.com

buganizer.corp.google.com is an alias for uberproxy.l.google.com.

uberproxy.l.google.com has address 142.250.141.129

uberproxy.l.google.com has IPv6 address 2607:f8b0:4023:c0b::81

Google's corp services are publicly accessible in that sense - but you're not getting through the proxy without valid credentials and (in most cases) device identity verification.

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

#118
post #31

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

In practice, the DoD right now uses something called AppGate, which downloads a script on-demand to check for device compliance, and it supports free software distributions, but the script isn't super sophisticated and relies heavily on being able to detect the OS flavor and assumes you're using the blessed package manager, so right now it only works for Debian and RedHat descended Linux flavors. It basically just goes down a checklist of STIG guidelines where they are practical to actually check, and doesn't go anywhere near the level of expecting you to have a signed bootloader and a TPM or checking that all of the binaries on your device have been signed.

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

#119

TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life. TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker. The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general…

the advantage of fido2/webauthn is actually biggest for non techies. tech people are the ones who won't fall for take bad phishing attempts. stopping malicious logins from fake sites is a massive win.

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

#120

TOTP is not going anywhere for much of the Internet. Hold on while I get a Yuibikey to my dad who thinks "folders can't be in other folders" because that's not how they work in real life. TOTP is a great security enhancement, and while phishable, considerably raises the bar for an attacker. The fact that TOTP is mentioned as a bad practice in this document is an indicator that this should not be considered a general…

Yubikeys aren't the serious long-term alternative to TOTP; software keys embedded in phones are what we're going to end up with.
Post reply on HN