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

81–90 of 369 posts

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

#81

Post by tablespoon »

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

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

Is that really a problem? In practice wouldn't it just mean you can only use employer-provided and certified devices? If they want to provide their employees some Free Software-based client system, that configuration would be on the whitelist.

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

#82

Post by shkkmo »

nybble41 wrote: post #44
MattPalmer1086 wrote: post #19

Earlier quoted context omitted.

It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?

"Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet . In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be…

Which is saying that agencies have to stop relying on / requiring VPNs for authorization and access control, not that any user has to stop using VPNs.

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

#83

Post by zajio1am »

uncomputation wrote: post #5

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

Well, we can just move from traditional VPNs to IPSec in transport mode.

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

#84

Post by Terretta »

I'm not sure that ...

> “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications."

... necessarily means TOTP.

Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably one could take "supply one-time codes" to rule out both what HSBC does, but also what Apple does pushing a one-time code displayed together with a map to a different device (but sometimes the same device).

I'd argue TOTP is more akin to an open soft hardware token, as after initial delivery it works entirely offline, and passes the "something I have" check.

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

#85

Post by nextos »

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…

> 1. No more SMS and TOTP. FIDO2 tokens only.

SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives.

However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.

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

#86

Post by tptacek »

nextos wrote: post #85
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…

> 1. No more SMS and TOTP. FIDO2 tokens only. SMS are bad due to MITM and SIM cloning. In EU many banks still use smsTAN, and it leads to lots of security breaches. It's frustrating some don't offer any alternatives. However, is FIDO2 better than chipTAN or similar? I like simple airgapped 2FAs, but I'm not an expert.

The major advantage of FIDO2 is that it's difficult to phish. SIM cloning is not the primary reason organizations are now advocating against SMS 2FA.

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

#88

Post by kelnos »

reginaldo wrote: post #39
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.…

It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.

It "should" suffice, but entities like banks and media companies are already going beyond this. As the parent points out, many financial and media apps on Android will just simply not work if the OS build is not signed by a manufacturer on Google's list. Build your own Android ROM (or even use a build of one of the popular alternative ROMs) and you lose access to all those apps.

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

#89

Post by nybble41 »

shkkmo wrote: post #82
nybble41 wrote: post #44

Earlier quoted context omitted.

"Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet . In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be…

Which is saying that agencies have to stop relying on / requiring VPNs for authorization and access control, not that any user has to stop using VPNs.

It's true that they didn't mandate detecting and blocking accesses from VPNs, if the user chooses to connect through one. However, they pretty clearly are saying that the application should be exposed to the public Internet, which is the opposite of what enriquto claimed[0] earlier in this thread:

> As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed.

[0] https://news.ycombinator.com/item?id=30103558

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

#90

Post by kelnos »

c0l0 wrote: post #67
seibelj wrote: post #34

Earlier quoted context omitted.

Reproducible builds are a thing, I don't know how widespread they are. I know the monero project has that built in so everyone compiles the exact same executable regardless of environment, and can verify the hash against the official version https://github.com/monero-project/monero

Let me elaborate on the problem I do have with remote attestation, no matter if I can verify that the signed binary is identical with something I can build on my own. I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setti…

I hadn't thought about extending this attestation to the browser build as a way to lock down web banking access. That's truly scary, as my desktop Linux build of Firefox might not qualify, if this sort of thing would come to pass.
Post reply on HN