Most active commenters
  • Godel_unicode(4)
  • Terretta(3)

←back to thread

656 points EthanHeilman | 14 comments | | HN request time: 1.119s | source | bottom
Show context
Terretta ◴[] No.30105267[source]
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 one could take "supply one-time codes" to rule out both what HSBC does, but also what Apple does pushing a one-time code displayed together with a map to a different device (but sometimes the same device).

I'd argue TOTP is more akin to an open soft hardware token, as after initial delivery it works entirely offline, and passes the "something I have" check.

replies(1): >>30105736 #
1. kelnos ◴[] No.30105736[source]
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.

replies(3): >>30105850 #>>30106024 #>>30123461 #
2. Godel_unicode ◴[] No.30105850[source]
All of this is really government we-don't-pick-winners speak for yubikeys.
replies(3): >>30106031 #>>30106640 #>>30107124 #
3. Terretta ◴[] No.30106024[source]
> 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.

replies(2): >>30109095 #>>30109630 #
4. Terretta ◴[] No.30106031[source]
This makes sense. :-)
5. sodality2 ◴[] No.30106640[source]
My OpenSK chip begs to differ. https://github.com/google/OpenSK
replies(1): >>30107660 #
6. count ◴[] No.30107124[source]
PIV/CAC Smartcards.
replies(1): >>30107830 #
7. Godel_unicode ◴[] No.30107660{3}[source]
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."

replies(1): >>30113646 #
8. Godel_unicode ◴[] No.30107830{3}[source]
That's an interesting subject, since there has been a lot of government push for PIV but the internet has essentially decided that FIDO2/webauthn are the way forward and making them work with PIV is non-trivial.
replies(1): >>30109490 #
9. withinboredom ◴[] No.30109095[source]
Yubikey has a setting to always require a pin before touch. So leaving it always plugged in isn’t that big of a deal.
10. count ◴[] No.30109490{4}[source]
Agreed. Strong authentication vs. strong identity proofing.
11. tialaramex ◴[] No.30109630[source]
However the set of attackers who can get any advantage from the laptop sat on a conference table, much less your desk at home or in the office building, is both different and much less scary than the arbitrary crooks phishing people from the far side of the Internet.
12. tialaramex ◴[] No.30113646{4}[source]
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 - but actually it's the contractor's iPhone, which can do the exact same trick. Or maybe it's a Pixel, or whatever the high-end Samsung phone is today.

That's what standardisation gets us. If CoolPhone Co. build a phone that actually uses a retina scan to unlock, they can do WebAuthn and deliver that security to your systems without you even touching your software. And yes, in the Hollywood movie version the tricky part is the synthetic eyeball so as to trick the retina scanner, but in the real world the problem is after you steal the ambassador's CoolPhone she can't play Wordle and she reports the problem to IT before you can conduct your break-in, synthetic eyeball or not.

replies(1): >>30119524 #
13. Godel_unicode ◴[] No.30119524{5}[source]
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.

14. rstuart4133 ◴[] No.30123461[source]
> No, I'd expect it does include TOTP

I'd expect it to be any mechanism that doesn't do mutual authentication. In other words the authentication not only proves to the service your "you", it also proves to you the service is the one you think you are authenticating to. And it does that reliably even in the face of a MITM attack.

It's damned hard to do, and obviously none of SMS, TOTP and passwords do it. https + passwords was supposed to do it and technically does do it, but in practice no one looks at the domain name. Email + DKIM could do it, but no email client shows you outcome of DKIM auth and again no one would look at that anyway.

WebAuthn / FIDO2 does do it. It's undoubtedly the best option right now, but until tokens that open source + reproducible build right down to the metal, they aren't "Zero-Trust". You are forced to trust Yubi or Google or whatever as the tokens they give you are effectively black boxes. Worse, because an open source token means "easily build-able many companies" and thus means "WebAuthn tokens become a commodity", I expect Yubi to fight it to their dying breath.