Live data from Hacker News

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

bastionzero.com

301–310 of 369 posts

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

#301
post #242
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.

For something like LineageOS, ironically, the solution is to root your device to adjust build properties so it looks signed. My vanilla LineageOS install fails but I can root with Magisk, enable Zygisk to inject code into Android, edit build properties, add SafetyNet fix and now my device is good to go? It's crazy to think the workaround is "enable arbitrary code injection" (Zygisk)

This, or we could have dual booting that's relatively as easy to do on mobile as it is on PCs.

Currently, you'd have to do find an unlocked phone, hope there is a downloadable factory image, re-flash, re-lock, re-install to run whatever needs attestation. Potentially using something like Android's DSU feature, this could all be a click or two, and you could be back running Lineage with a restart.

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

#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 up with, and promote such a framework the world would become a different place.

BTW, the linked article is mostly based on misconceptions:

* https://articles.59.ca/doku.php?id=pgpfan:tpp

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

#304

Earlier quoted context omitted.

Is DANE @tptacek approved of? You say DNSSEC and it triggers my internal alarm bells.

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

No post body was provided.

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

#305
post #25

Earlier quoted context omitted.

What happens to the people who are not banked?

There are alternatives. For example, MiniID and BuypassID.

From what I can tell, both of those are only for Norway?

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

#306

This sounds really beautiful, and I am saving the link for future reference. I'm curious about the DNS encryption recommendation. My impression was that DNSSEC was kind of frowned upon as doing nothing that provides real security, at least according to the folks I try to pay attention to. Are these due to differing perspectives in conflict, or am I missing something?

Whatever happened to Dnscrypt?

They never even wrote a Draft RFC.

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

#307
post #27

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…

What's wrong with TOTP?

MITM phishing attacks (also called real time phishing).

If someone just put a fake domain that proxies everything between you and the server (with fake domain with HTTPS... which he social engineered you to get on)

Looks like FIDO2 2FA only sign the challenge response against the server certificate available locally (= the phishing domain) so just passing it to the original server will fail. Also, the attacker can't just re-sign the challenge response after you, because the challenge was sent from the original server already encrypted with the public key of the user (stored from the registration phase). So only the registered user can see the challenge and respond to it.

This leaves only 2 options to do a phishing attack: 1) Get a valid certificate for the original domain [1] 2) force downgrade the user to old TOTP [2]

[1] https://security.stackexchange.com/q/157756/69837

[2] https://eprint.iacr.org/2020/1298.pdf

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

#308

Earlier quoted context omitted.

This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies. I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.

What bank doesn't have a regular web app?

It's about the EU mandated 2FA auth for online shopping.

E.g. with an credit card.

Due to the way it integrates into websites (or more specifically doesn't) classical approaches like SMS 2FA (insecure anyway) but also TOTP or FIDO2 do not work.

Instead a notification is send to a preconfigured app where you then confirm it.

Furthermore as the app and payment might be on the same device the app uses the fingerprint reader/(probably some Google TPM/secrets API idk.).

Theoretically other approaches should work, but practically they tend to not work reliable or at all in most situations.

Technically web based solutions could be possible by combining a FIDO stick with browser based push notifications, practicality they (Banks) bother or there are legal anoyences.

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

#309

>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 corporate rug-pulling, not because it failed to catch on. Whereas encrypted email really hasn't caught on anywhere.

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

#310

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…

This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies. I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.

  I think we'd do well to provide the option to use open protocols when possible.
Of course, the PR copy just writes itself, doesn't it? AD administrators, Apple and Google, banks and everyone else can benefit from context aware authorization.

If the state of your phone is stolen or "compromised", you want immediate Peace of Mind.

Even if it's just misplaced, having that kind of flexibility is just great.

Post reply on HN