Live data from Hacker News

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

bastionzero.com

91–100 of 369 posts

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

#91

I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably o…

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 SMS to the victim, saying something like "Hello, this is a security check from Your Super Secure Bank. Please respond with the current code from your Authenticator app." Then they get the code and enter it on their side, and are logged into your bank account. Sure, many people will not fall for this, but some people will, and that minority still makes this attack worthwhile.

A hardware security token isn't vulnerable to this sort of attack.

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

#92
post #91

I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably o…

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…

All of this is really government we-don't-pick-winners speak for yubikeys.

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

#93

I’m somewhat unhappy the “zero trust” terminology ha caught on. The technology is fine, but trust is an essential concept in many parts of life[0], and positioning it as something to be avoided or abolished will just further erode the relationships that define a peaceful and civil society. 0: trade only works if the sum of your trust in the legal system, intermediates, and counterparts reaches some threshold. The sam…

Couldn't agree more on this being bad terminology. Something is always implicitly trusted. Whether it's your root CA certificates, your Infineon TPM, the Intel hardware in your box, or something else. When I first saw this term pop-up I thought it meant something completely different than it does, I guess because of the domain I work in.

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

#94
post #88

Earlier quoted context omitted.

It depends on the level of attestation required. A simple client certificate should suffice for the majority of the non-DoD applications.

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 they're the largest user bases and offer a turn-key feature, and the market doesn't want to do addition custom work to support alternatives.

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

#95
post #91

I'm not sure that ... > “discontinue support for protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications." ... necessarily means TOTP. Could be argued "supply" means code-over-the-wire, so all 3 being things with a threat of MITM or interception: SMS, calls, "supply" of codes, or push. Taken that way, all three fail the "something I have" check. So arguably o…

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.

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

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

All of this is really government we-don't-pick-winners speak for yubikeys.

This makes sense. :-)

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

#97
post #21

Earlier quoted context omitted.

There's significant bi-partisan resistance, in the US, to anything like a national ID, unfortunately, with the result that we have one anyway (because of course we do, the modern world doesn't work without it) it's just an ad-hoc combination of other forms of ID, terrible to work with, heavily reliant on commercial 3rd parties, unreliable, and laughably insecure. But the end result is still a whole bunch of public an…

I've done some thinking about this, and a possible solution is a bunch of cross signed CA's like the Federal common policy / FPKI for cross trust amongst federal agencies, but done at a state DMV / DPS level. Driver's licenses / state IDs could have certs embedded into the cards and then be used for things like accessing government websites, banks, etc. Yes there are some access concerns, and some privacy concerns th…

Would that look anything like the REAL ID system?[0]

[0]https://www.tsa.gov/real-id

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

#98

Earlier quoted context omitted.

I'm America, about 30% of the population would start screaming about the Mark of the Beast if we tried to roll out something like this.

There is a large contingent of non-religious people who are against it on civil liberties grounds. The resistance to it truly crosses both parties, and it requires the cooperation of the States, which makes it politically non-viable as a practical matter.

The thing I don't get about the non-religious arguments is that we already have a national ID, it's just a patchwork system of unreliable, not-particularly-secure forms of identification that are a pain in the ass for a regular citizen to have to deal with. And the REAL ID stuff essentially makes state IDs conform to a national ID specification anyway.

And regardless, if you do want a national US ID, you just get a passport, and it'll be accepted as a form of ID everywhere a state-issued driver's license or state ID is accepted. Of course, in this case it's technically voluntary, and many Americans don't travel internationally and don't bother to get a passport.

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

#99

Here in Norway we have BankID which uses MFA. To access any government, banking, or official system you have to authenticate with your BankID. Its simple amazing.

That's all good except for the 'bank' part. It was expedient but banks are not the orgs. that should be running that. Every nation needs to turn their Drivers ID and Passport authorities into 'Ministry of Identity' and issue fobs, passwords that can be used on the basis of some standard. Or something like that, maybe quasi distributed.

I hear people say all the time that, in the US, the Postal Service would be great for this, and I can't help but agree. Sure, they'd have to develop in-house expertise around these sorts of security systems (just as any new federal government agency put in charge of this would have to do), which could be difficult. But they have the ability to distribute forms, documentation, and tokens to pretty much everyone in the US, with physical locations nearly everywhere that can be used to reach those who don't have physical addresses.

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

#100
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?

Post reply on HN