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

161–170 of 369 posts

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

#161

Post by carbonx »

meepmorp wrote: post #17
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…

Also, “Password policies must not require use of special characters or regular rotation.” They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

I worked for the govn't ~20 year ago - in IT - and even I hated our password policies. I just kept iterating the same password because we had to change it every 6 weeks.

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

#163

Post by no_time »

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

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

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

#164

Post by dpatterbee »

hansvm wrote: post #137
Signez wrote: post #36

Earlier quoted context omitted.

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…

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.

I feel like the issue with the post you mention was the absence of recourse rather than the locking out itself.

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

#165

Post by 0xffff2 »

ineedasername wrote: post #162

>It tells us to stop rotating passwords Finally! Maybe the places I've worked will finally listen. But I stopped reading TFA to praise this, so back to TFA.

NIST has made this recommendation for years. Sadly, I work for another branch of the Federal government and despite the NIST guidance I still have to rotate my password every 60 days. (Actually, the starts sending me daily emails warning me 15 days out, and the date is based on last change, so practically it's more like 45 days.)

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

#166

Post by bradstewart »

tptacek wrote: post #53
pitaj wrote: post #27

Earlier quoted context omitted.

What's wrong with TOTP?

It's very phishable. Attackers will send text messages to your users saying "Hi, this is Steve with the FooCorp Security Team; we're sorry for the inconvenience, but we're verifying everyone's authentication. Can you please reply with the code on your phone?" It's even worse with texted codes because it's inherently credible in the moment because the message knows something you feel it shouldn't --- that you just got…

They also come from (seemingly) random phone numbers and/or short codes, with absolutely no way to verify them.

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

#167

Post by nybble41 »

jacobr1 wrote: post #109
InitialLastName wrote: post #79

Earlier quoted context omitted.

> no organization should have that level of control over devices owned by employees, vendors, customers, or anyone else who requires access to the organization's services. It seems like the sensible rule of thumb is: If your organization needs that level of control, it's on your organization to provide the device.

Or we could better adopt secure/confidential computing enclaves. This would allow the organization to have control over the silo'd apps and validate some degree of security (code tampering, memory encryption, etc) but not need to trust that other apps on the device or even the OS weren't compromised.

Secure enclaves are still dependent on someone other than the owner (usually the manufacturer) having ultimate control over the device. Otherwise the relying party has no reason to believe that the enclave is secure.

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

#168

Post by mindslight »

bigiain wrote: post #139
kelnos wrote: post #88

Earlier quoted context omitted.

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.

I’m not even so sure I’m totally against banks doing that either. From where I sit right now, I have within arms reach my MacBook, a Win11 Thinkpad, a half a dozen Raspberry Pis (including a 400), 2 iPhones only one of which is rooted, an iPad (unrooted) a Pinebook, a Pine Phone, and 4 Samsung phones one with its stock Android7 EOLed final update and three rooted/jailbroken with various Lineage versions. I have way w…

Putting a banking app on your pocket surveillance device is one of the least secure things you can do. What happens if you're mugged, forced to login to your account, and then based on your balance it escalates to a kidnapping or class resentment beatdown? Furthermore, what happens if the muggers force you to transfer money and your bank refuses to roll back as unauthorized because their snake oil systems show that everything was "secure" ?

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

#169

Post by pishpash »

Signez wrote: post #36
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.…

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…

Who gets to decide what changes are kosher? Sounds like bureaucratic behavior modeling.

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

#170

Post by EthanHeilman »

KarlKemp wrote: post #22

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…

Minimizing trust should always be a goal of a security system. If you can minimize trust without harming usability, compatibility, capability, security, cost, etc... you should do it.

When we talk about trust we often mean different things:

* In cryptography and security by "trust" we mean a party or subsystems that if they fail or are compromised then the system may experience a failure. I need to trust that my local city is not putting lead in the drinking water. If someone could design plumping that removed lead from water and cost the same to install as regular pipes than cities should install those pipes to reduce the costs of a trust failure.

* In other settings when we talk about trust we are often talking about trust-worthiness. My local city is trustworthy so I can drink the tap water without fear of lead poisoning.

As a society we should both increase trustworthiness and reduce trust assumptions. Doing both of these will increase societal trust. I trust my city isn't putting lead in the drinking water because they are trustworthy but also because some independent agency tests the drinking water for lead. To build societal trust, verify.

Post reply on HN