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

331–340 of 369 posts

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

#331

Post by Dylan16807 »

themacguffinman wrote: post #323
Dylan16807 wrote: post #285

Earlier quoted context omitted.

That might at least be half a reasonable argument if they didn't all allow desktop logins that could be stuffed with malware. > they're not obligated to deal with whatever insecure garbage you turn your phone into Banks probably should be obligated to let you connect over standard protocols.

In practice, many credit unions/banks will only support recent versions of major desktop browsers (ie. the big three: Chrome, Firefox, Safari) which are known to mandate a good level of security. These browsers will usually have their own OS requirements. For eg Safari is tied to macOS versions directly while Chrome will drop support for older unmaintained operating systems like Windows XP. Any system can have malwar…

So require I have an up to date browser on my phone. Don't require that I haven't rooted it when every desktop is in an equivalent security state. That's not enough to be "unusually vulnerable".

I'm not asking to use a 10 year old version of android that no modern browsers support any more and is missing many security features.

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

#332

Post by fire »

vel0city wrote: post #327
fire wrote: post #273

Earlier quoted context omitted.

From my experience it isn't a be-all-end-all so much as another point of data for anomaly detection. In practice, geoip "regions" like used for this _are_ on the larger scale, yes; However that still lets you ask valuable questions like "why is this user who logs in from Vermont, USA suddenly in Hungary?" and potentially do something proactive like limiting that session's resource access until a new MFA challenge has…

> "why is this user who logs in from Vermont, USA suddenly in Hungary?" Maybe because the new login is from a hacker. Maybe because your geoip database provider is unreliable. Either one is likely. There's no sure way to go from an IP address to a location.

Right; I covered that explicitly further down in the post.

I wish I had made it more clear in my original post that Impossible Traveler checks are not a magic bullet, as most are assuming that this would be used all on its own for whether to bar access.

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

#333

Post by joshuamorton »

mjg59 wrote: post #117
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.

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

Not to mention login.corp.google.com (which has been on the frontpage of HN before!).

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

#334

Post by upofadown »

lolinder wrote: post #329
upofadown wrote: post #316

Earlier quoted context omitted.

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

To call encrypted messaging a complete failure you have to demonstrate that the percentage of people capable of maintaining secure messaging is stagnant. As far as I can see, the opposite is true. It is easier than ever to establish and maintain a secure communication channel. The Signal study showed that the majority of people were unable to understand Signal's security features, but not that the security model is b…

That assumes that usability is actually getting better. There is no evidence that this is the case from usability studies. This is not a new problem and we have known what is wrong for something like 20 years now. This isn't something I just thought of. See: Why Johnny Can't Encrypt[1].

[1] https://www.usenix.org/legacy/events/sec99/full_papers/whitt...

[1] https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Ca...

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

#335

Post by dathinab »

themacguffinman wrote: post #326
dathinab wrote: post #320

Earlier quoted context omitted.

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…

> 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. Android will block non-Play-Store app installations by default, and root is required for lower level access/capabilities that can bypass the normal sandbox. I'm honestly not sure what you're saying about 2FA in the rest of your comment, it's kind of vague an…

> installations by default

No, you basically have to click on ok once (or change a setting, depending on phone), either way it doesn't require root, and doesn't really change the attack scenario as it's based one someone intentionally installing an app from an arbitrary not-trusted source.

> root is required

Yeah, like privilege escalation attacks. As you will likely find in many compromised apps. And which on many Android phones work due to vendors not providing updates after some time. And many other reasons.

> What exactly are you referring to when you say "pretending to have proper 2FA"?

EU law says they need to provide 2FA for only banking.

Banks often don't do that for banking apps as it's inconvenient. Instead they "split the banking app in two parts" and maybe throw some finger pint based auth mechanism in and claim they have proper 2FA auth. (Because it's two app processes running and requires the fingerprint.) Through repeatedly security researchers have shown that its not a good idea.

Additionally they then require you to only use your fingerprint, not an additional password....

Either way, the point is that secure online banking doesn't requires locked down devices in general.

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

#336

Post by dathinab »

themacguffinman wrote: post #324
dathinab wrote: post #319

Earlier quoted context omitted.

> 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

You're right, many secure apps don't go far enough in blocking Android releases that are probably too old & vulnerable. Not all apps are perfect, but blocking rooted and ancient devices is a start.

No, it's starting at the wrong end and not in any relevant way provide an improvement.

Checking for an too old & vulnerable is where you start.

And then you can consider to maybe also block other stuff.

There is nothing inherently less secure about an rooted device.

Sure you can make it less secure if you install bad software, but you can also make it more secure.

Or you just need to lower the minimal screen brightness for accessibility reasons.

Your claiming it's ok to take the agency from people away to decide over a major part of their live (which sadly phones are today) because maybe they could act irresponsible and do something stupid.

But if we say that is ok, then we first need to start to ban cars, because you could drive into a wall with it, and knifes, also no way to have a bath tube you could drown yourself.

And yes that is sarcastic, but there is a big difference between something being "inherently insecure" (driving without belt) or by default is in no way less secure as long as you don't go actively out of your way to make it less secure (by e.g. disabling security protections).

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

#337

Post by freedomben »

blackrobot wrote: post #258
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 don't you share a TOTP between all of you? Just take a screenshot of the authenticator QR code, or save it to a shared 1password secret. Google's login protection mechanisms seem to be satisfied by TOTP usage, and you won't be locked out anymore (or at least much less likely to be).

You're right that would totally work with Google. In our case the boss is quite computer illiterate and trying to get him to use LastPass was hard enough. He will tolerate a lot of pain from getting locked out before he'll be willing to learn TOTP :-(

And for many of the SaaS that we use, TOTP doesn't help you avoid the security lock outs.

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

#338

Post by AaronFriel »

Hikikomori wrote: post #294
AaronFriel wrote: post #269

Earlier quoted context omitted.

The memo you're linking to was recently updated and did have force. The DOD, one of the largest federal agencies, issued its own memo with similar deadlines, and this & others have had the result of jumpstarting IPv6 / dual stack support for all of the major clouds & Kubernetes. If FedRAMP qualification is tied to IPv6 support, you'll see every major contractor and cloud provider support it promptly. If you look at t…

Yeah AWS has added a lot of ipv6 support recently, like ipv6 only subnets so you can actually benefit from using ipv6. Waiting for rds support though. Azure is so far behind on this it's silly.

What doesn't work with IPv6 on Azure? I understood they were first to support it of the major clouds, though maybe it was just in preview support for a long time.

I think in 2019 I was able to use IPv6 VNETs.

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

#339

Post by rstuart4133 »

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

> I think 3. is very harmful for actual, real-world use of Free Software.

I hold the reverse view. The only security token I'd trust is the only thing that isn't open is the private keys the device generates when you press the reset button. The rest meaning from the CPU up (say RISC-V) and the firmware must be open to inspection by anybody. In fact, it should also be easy to peel away the silicon protection so you can see everything bar the cells storing the private keys. The other non-negotiable is the thing that computes and transmits the "measures" of the system being attested to (including it’s own firmware) can not be changed - meaning no stinking "security" patches are allowed at that level. If it's found broken, throw it away as the attestation is useless.

The attestation then becomes the device you hold is faithful rendering / compiling of open source design document X by open source compiler Y. And I can prove that myself, by doing building X using Y and verifying the end result looks like the device I hold. This process is also known as reproducible builds.

What we have now (eg, YubiKeys) is not that. Therefore I have to trust Yubi Corp. To see what that's a problem, see the title of this story. It has the words "Zero-Trust" in it.

In reality of course there is no such thing as "Zero-Trust". I will never be able to verify everything myself, ergo I have to trust something. The point is there is a world of difference between trusting an opaque black box like Yubi Corp, and trusting an open source reproducible build, where a cast of random thousands can crawl over it and say, "it seems OK to me". In reality it's not the ones that say "it seems OK" you are trusting. You are trusting the mass media (places like this in other words), to pick up and amplify the one voice among millions that says "I've found a bug - and because it's open I can prove it" so everyone hears it.

So to me it looks to be the reverse of what you say. Remote attestation won't kill software freedom. Remote attestation, done in a way that we can trust, must be built using open source. Anything less simply won’t work.

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

#340

Post by rstuart4133 »

thinkmassive wrote: post #268
pabs3 wrote: post #189

Earlier quoted context omitted.

Identical source code when recompiled should produce identical binaries: https://reproducible-builds.org/ Agreed that people should have the freedom to modify their software though.

A remote cryptographically-signed attestation is not reproducible https://developer.android.com/training/safetynet/attestation

> A remote cryptographically-signed attestation is not reproducible

No one wants to reproduce an attestation. If you could, it could be copied, and if you can copy an attestation any hardware could send it to prove it was something else - something the other end trusts, rendering is useless for it's intended purpose.

However, the attestation is attesting the hardware you are running on is indeed "reproduced", as in it is a reliable copy of something the other end trusts. It could be a device from Yubi Key and in effect you are trusting Yubi Corp's word on the matter. Or, it could be an open source design everybody can inspect, reproducibly rendered in hardware and firmware. Personally, I think trusting the former is madness, as is trusting the latter without a reproducible build.

Post reply on HN