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

191–200 of 369 posts

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

#191

Post by curmudgeon81 »

notatoad wrote: post #188
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.…

If you can argue that remote attestation doesn't provide additional security, then i'd love to hear that argument. but it seems like a fairly clear-cut case that it does provide additional security, and i don't think it's reasonable to accept a lower level of security for the sake of allowing unverified builds of open-source software. there are specific contexts where you want to distribute information as widely as p…

A server rate limiting login attempts is additional security.

A remote system asked to promise it's what it says it is: the illusion of security.

Jailbreaking, DRM, etc are all evidence of this illusion.

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

#192

Post by withinboredom »

ethbr0 wrote: post #94
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.

The clearer way to put this is: when faced with a regulatory requirement, most of the market will choose whatever pre-packaged solution most easily satisfies the requirement. In the case of client attestation, this is how we get "Let Google/Apple/Microsoft handle that, and use what they produce." And as a end state, leads to a world where large, for-profit companies provide the only whitelisted solutions, because the…

In my experience, it isn’t that companies don’t want to put in the work, it’s that some middle manager made a decision. I’ve been told to “implement login with X” more than once in my career and when asked what about Y or Z, they say, “we only want X” with no further explanation.

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

#193

Post by Alex3917 »

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…

Given that every cybersecurity czar seems to publicly resign a few months after being appointed, what are the chances of these actually being implemented?

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

#194

Post by tssva »

mnd999 wrote: post #156
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…

Bleeding edge or complete fantasy? This is going to be very very expensive and guess who’s going to be paying for it?

As with most OMB memos it is complete fantasy and agencies won't comply by the date, any date close to it or really ever. The answer to the question "who's going to be paying for it?" is nobody which is why it will never actually get done.

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

#195

Post by withinboredom »

codemac wrote: post #127
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…

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 logging in for you!

To be clear, I don’t have a better solution. But all the second factor stuff is fundamentally broke when you are likely to need access to the service most.

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

#196

Post by tomrod »

lupire wrote: post #146
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…

Free software doesn't really work in a networked untrusted world.

Why?

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

#197

Post by withinboredom »

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…

Aren’t you talking about sms auth?

The issue with TOTP is that it’s usually not rate limited. Just sit there guessing codes and you’ll eventually get in.

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

#199

Post by joe-collins »

dpatterbee wrote: post #164
hansvm wrote: post #137

Earlier quoted context omitted.

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.

Absolutely. The escalation chain is its own attack vector, but it should exist.

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

#200

Post by withinboredom »

Terretta wrote: post #95
kelnos wrote: 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…

> via SMS Or push, or other supply of a code from somewhere. It's just oddly worded, sounding like the code in all 3 cases is coming over the wire. Granted, phishing is a diff story, but in practice, I see Yubikeys permanently inserted to their laptop hosts, requiring even less intervention.

Yubikey has a setting to always require a pin before touch. So leaving it always plugged in isn’t that big of a deal.
Post reply on HN