←back to thread

656 points EthanHeilman | 1 comments | | HN request time: 0.216s | source
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 #
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 #
1. 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.