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

321–330 of 369 posts

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

#321

Post by Godel_unicode »

tialaramex wrote: post #298
Godel_unicode wrote: post #152

Earlier quoted context omitted.

The disclaimer on the linked page agrees with me. "This project is proof-of-concept and a research platform. It is NOT meant for a daily usage. The cryptography implementations are not resistent against side-channel attacks."

There are a lot of other providers in this space, Yubico are the best known and probably one of the more competent offerings, but this is not a situation where the government is picking a winner by picking a standard. A bunch of situations aren't going to end up with a separate physical authenticator anyway, they'll do WebAuthn, which in principle could be a Yubico Security Key or any of a dozen competitor products -…

There are not a lot of providers on the FIPS list though. Coupled with the fact that virtually all government employees use Windows computers, and you end up right back where we started. The only real competition is Windows hello.

The various auth apps are problematic because they usually come with some kind of requirement for intune or similar to do remote attestation. That's a weird place for the government to be with contractors, since a lot of those contacts don't have language requiring that contractors have a phone at all, much less that they allow the federal government to MDM it.

It could be providers other than yubico, but it won't be.

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

#322

Post by _RafaelKr »

freedomben wrote: post #314
pagnol wrote: post #250

Earlier quoted context omitted.

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!

I recently setup a WireGuard VPN and it was surprisingly easy (compared to other VPN solutions) and works very reliable for me.

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

#323

Post by themacguffinman »

Dylan16807 wrote: post #285
themacguffinman wrote: post #208

Earlier quoted context omitted.

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

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 malware. That's not the point. To repeat my point again: client restrictions are about making sure user devices are not unusually vulnerable to malware. For example, any Windows device may be infected with malware, but if you're still running Windows XP you're vulnerable to a much larger variety of known malware and more severe exploits. Hence why businesses will want to support only modern versions of eg Chrome which itself will require modern versions of operating systems.

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

#324

Post by themacguffinman »

dathinab wrote: post #319
themacguffinman wrote: post #208

Earlier quoted context omitted.

> 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

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.

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

#325

Post by vel0city »

fire wrote: post #80

I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks? For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation The idea is that if a pair of events breaches that minimum tra…

Geolocation is often unreliable. There's no sure way to go from IP address to accurate location, its all based on guesses on how things got routed previously. My previous home routinely showed up as a different country in many different geoip databases, so for me something like that would have always instant-banned me if I switched from cellular (which a lot of databases places me about 100mi away from my home) to home WiFi that would show a jump of 1,000mi.

Even giant orgs like Google who should be good at this will fail at this. I've had services with their Cloud Armor set to disallow connectivity from non-US connections, and yet connections in the US get flagged as non-US even when a traceroute shows no hops going overseas.

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

#326

Post by themacguffinman »

dathinab wrote: post #320
themacguffinman wrote: post #208

Earlier quoted context omitted.

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

> 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 and there are some possible typos/grammar issues that confuse me. What exactly are you referring to when you say "pretending to have proper 2FA"?

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

#327

Post by vel0city »

fire wrote: post #273
judge2020 wrote: post #111

Earlier quoted context omitted.

Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.

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.

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

#328

Post by nybble41 »

staticassertion wrote: post #220
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.…

I wish I had responded earlier, because now this entire thread is full of nonsense and I can't really respond to everything. But attestation can mean a lot of things and isn't inherently in conflict with free software. For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy. Free software would only, in theory, need a digital signature so…

> For example, at my company we validate that laptops follow our corporate policy, which includes a default-deny app installation policy.

Presumably (hopefully) these are corporate-owned devices, with a policy like that. Remote attestation is fine if it's controlled by the device's owner, and you can certainly run free software on such a device, if that particular build of the software has been "blessed" by the corporation. However, the user doesn't get the freedoms which are supposed to come with free software; in particular, they can't build and run a modified version without first obtaining someone else's approval. At the very least it suggests a certain lack of respect for your employees to lock down the tools they are required to use for their job to this extent.

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

#329

Post by lolinder »

upofadown wrote: post #316
lolinder wrote: post #309

Earlier quoted context omitted.

> 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 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 broken. The question at hand isn't how many people are using it wrong but how many people are using it right that never could have managed to do so with PGP keys. If even 10% of Signal's users successfully maintain a secure channel, you're looking at around 5 million people, most of whom probably would not have been able to set up secure messaging without Signal.

Do we still have work to do? Of course! But that doesn't mean that we've failed in our efforts so far.

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

#330

Post by lethargic_meat »

formerly_proven wrote: post #8
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.

It's a different framing to get rid of figleafs. Everything has to be built so that it actually has a chance of being secure - if your state of mind is "this is exposed to the public internet", BS excuses like "this is only exposed to the TotallySecure intranet" don't work any more, because they don't work in the first place. Perimeter security only works in exceedingly narrow circumstances which don't apply - and ha…

This sounds like the meme of holding a riffle like a pistol, so your fear for getting smacked with the butt makes you impervious to recoil.
Post reply on HN