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

311–320 of 369 posts

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

#311

Post by tptacek »

AndyMcConachie wrote: post #275
tptacek wrote: post #236

Earlier quoted context omitted.

No, DANE is very bad. But it's a dead-letter standard, so I don't worry about much.

You think no one is deploying DANE for SMTP? https://stats.dnssec-tools.org/images/domains.svg It's deployed on many more domains than MTA-STS.

Of course it is. There are only a couple of email providers that actually matter, but out in the long tail of domains that might never receive a single non-spam email, there are plenty that are auto-signed by registrars. It's telling that's the best evidence you have, and not, like, "Google Mail uses DANE".

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

#312

Post by tptacek »

xyzzy_plugh wrote: post #274
mjg59 wrote: post #267

Earlier quoted context omitted.

Most SSO solutions don't verify device identity or state, so you're not ensuring that the connection is coming from a computer you trust running software you trust.

I guess it's a matter of what the IdP attests. It's definitely possible for an IdP like Okta to include a ton of client details as part of the attestation payload. Stuff like GeoIP, client certificate fields, MDM status, etc.

Right, but you have to individually set up all of your apps to work with it; the proxy can be mandatory for all apps by dint of network controls.

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

#313

Post by idkyall »

shbooms wrote: post #101
tablespoon wrote: post #81

Earlier quoted context omitted.

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

I think from the viewpoint of a business/enterprise environment, yes you're right, context-aware authorization is a good thing. But I think the point of your parent comment's reply was that the inevitable adoption of this same techonology in the consumer-level environment is a bad thing. Among other things, it will allow big tech companies to have an stronger grip on what software/platforms are OK to use/not use. If…

>But if your TV streaming provider tells you have to use a certain version of Windows to consume their product, that's not considered acceptable to a good deal of people.

This is already the case with Netflix -- 4k video content cannot be played on Linux.

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

#314

Post by freedomben »

pagnol wrote: post #250
freedomben wrote: post #160

Earlier quoted context omitted.

It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what…

Have you considered using the same Proxy or VPN? I work remotely and sometimes access services through a VPN based in the country my coworkers are at specifically to avoid this kind of annoyance.

This is a great idea, although the boss is pretty technically challenged so getting him set up on it might be interesting. It's been extremely difficult just to teach him to use LastPass.

Much appreciate the suggestion!

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

#315

Post by freedomben »

throwaway48375 wrote: post #246
freedomben wrote: post #205

Earlier quoted context omitted.

The frustrating thing to me is that as a user they don't give us any tools to help ourselves. I would gladly make it a "team" account and login individually if we could. I would gladly do a shared TOTP, or whitelist login locations, or anything like that. Or at least give us the option to accept the risk and disable whatever anomaly detection they are applying. But no, that's not how the software world works anymore.…

Why do you need to all access the same account though? Can't you grant access to whatever resource you need to multiple accounts?

For some of them we can, for others no. Sadly it seems as though supporting this sort of thing is not a priority for most SaaS

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

#316

Post by upofadown »

lolinder wrote: post #309
upofadown wrote: post #302

>Meanwhile encryption with PGP has been a complete failure, due to problems with key distribution and user experience. Encrypted messaging has been a complete failure; there is no need to single out email. I suspect the reason is more or less the same in all cases. Users have not been provided with a conceptual framework that would allow them to use the tools in a reasonable way. If the US federal government can come…

> Encrypted messaging has been a complete failure; there is no need to single out email. Can you elaborate on why you see it this way? WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon. As far as I can tell, if we lose encrypted messaging at this point, it will be due to government action or corpor…

>WhatsApp has been wildly successful, my very non-technical in-laws use Signal for their family's conversations, and other messaging platforms are jumping on the bandwagon.

You only get effective end to end encryption if you can verify that you are talking to who you think you are talking to. Otherwise the people that are running the system can cause your messages to take an unencrypted detour and thus be able to read them. This is often called a man in the middle attack. Verifying identities normally means checking some sort of long identity number. Very few people know how to do that in an effective way.

For example: in a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. The usability of end to end encrypted messaging is a serious issue. We should not kid ourselves into thinking it is a solved issue.

PGP in a sense is actually better here in that it forces the user to comprehend the existence of a key in a way where it is intuitively obvious that it is important to know where that key came from.

[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

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

#317

Post by jacobr1 »

wizzwizz4 wrote: post #155
jacobr1 wrote: post #109

Earlier quoted context omitted.

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.

I'm uncomfortable letting organisations have control over the software that runs on my hardware. (Or, really, any hardware I'm compelled to use.) Suppose the course I've been studying for the past three years now uses $VideoService, but $VideoService uses remote attestation and gates the videos behind a retinal scan, ten distinct fingerprints, the last year's GPS history and the entire contents of my hard drive?¹ If…

So there are two levels of tradeoffs:

1) The requirements themselves. These are different for consumer vs employee type scenarios. So general, I'd prefer we err on the side of DRM free for things like media, but there are legitimate concerns around things like data privacy when you are an employee of an organization handling sensitive data.

2) Presuming there are legitimate reasons to have strong validation of the user and untampered software, we have the choice of A) using only organization supplied hardware in those case or B) using your own with some kind of restriction. I'd much prefer to use my own as much as possible ... if I can be ensured that it won't spy on me, or limit what I can do, for the non-organization specific purposes I've explicitly opted-in to enable.

> I'm uncomfortable letting organisations have control over the software that runs on my hardware.

I'm not, if we can sandbox. I'm fine with organizations running javascript in my browser for instance. Or running mobile apps that can access certain data with explicit permissions (like granting access to my photos so that I can share them in-app). I think we can do better with both more granular permissions, better UX, and cryptographic guarantees to both the user and the organization that both the computation and data is operating at the agreed level.

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

#318

Post by takumif »

tptacek wrote: post #120
unethical_ban wrote: post #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…

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

I have a newbie question: Can't we embed a hardware key into a phone, and that'd be just as good as a Yubikey? Do we already do this, or is there a reason why we don't?

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

#319

Post by dathinab »

themacguffinman wrote: post #208
dathinab wrote: post #135

Earlier quoted context omitted.

Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…

> but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them The point of these restrictions is to ensure that your device isn't unusually vulnerable to privilege escalation in the first place. If you let them, some users will root their phone, disable all protections, install an malware-filled Fortnite apk from a random website then stick their cr…

> privilege escalation in the first place.

it fails to do so in many ways, including not blocking old, no longer maintained, known to be vulnerable android releases

it also has little to do with moding and more with having a proper working free marked which allows alternatives besides Google and Apple

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

#320

Post by dathinab »

themacguffinman wrote: post #208
dathinab wrote: post #135

Earlier quoted context omitted.

Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…

> but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them The point of these restrictions is to ensure that your device isn't unusually vulnerable to privilege escalation in the first place. If you let them, some users will root their phone, disable all protections, install an malware-filled Fortnite apk from a random website then stick their cr…

As a side note the attack scenario you describe works without needing any rooting or anything it already exists and isn't detected by their security mechanism.

Also this is about the second factor in 2FA not online banking.

Which you can do on a completely messed up computer.

I'm also not asking to be able to do pay contactless with a degoogled Android phone.

Similar I'm but asking to not have 2FA, you can use stuff like a FIDO stick with your phone.

Most of this "security" features are often about Banks pretending to have proper 2FA without a second device... (And then applying them to other apps they produce, too).

Post reply on HN