Hacker News Reader

Comment by tptacek | Hacker News Reader

TOTP is phishable. The push to get away from TOTP is driven by phishing.

I've done authentication projects for financial institutions that were actively targeted by phishing attacks, and it is difficult to mitigate TOTP phishing. Defeating TOTP is very much in the standard playbook for high-dollar scam operations.

View on HN

The objection here isn't to something that uses public keys instead of TOTP. It's that they added support for remote attestation to passkeys, which an enormous red flag and enables That Which Is To Be Prevented, i.e. permanently entrenching the incumbents because many third parties won't support new device makers with no user adoption yet and users won't adopt a device that won't work with many third party services.

Moreover, the large majority of ordinary people are going to use whatever comes with their phone anyway, which can then lock the key in the device's secure processor by default independent of remote attestation. So then it's not getting you anything for those people and the primary thing it does is to impede Linux Girl from using Linux and anyone new from ever trying to create a competing mobile platform or even a usable non-Google fork of Android.

The obvious way to satisfy people is to remove support for remote attestation from the spec.

> The obvious way to satisfy people is to remove support for remote attestation from the spec.

If you presume bad faith on the part of basically the entire WebAuthn implementer community, how does this help?

The consumer passkey authenticator implementations of today do not provide attestations, passkey relying parties do not consume them, and both would need to intentionally ship changes to enact the scenario you're worried about. If you're worried about both of these colluding to lock you out of your accounts, it seems naive to think that changes to an (intentionally malleable, extensible) spec will protect you.

Adding support for something to the spec implies that somebody is intending to do it, or why would they add it? This implies that someone is acting in bad faith (or openly promoting a malicious feature), and the best way for the others to show that they aren't in on it is to evict them from the room and strip out the thing they were trying to insert.

Taking it out doesn't mean you don't have to remain vigilant that they might try put it back, but what does it say if they're unwilling to take it out?

It's in the spec because enterprises use it for corporate authentication scenarios, where they do have legitimate reasons to restrict which kinds of authenticators their employees can use.

Why is remote attestation required for this rather than just not issuing or enrolling authenticators you don't want?

Also, what are the legitimate reasons supposed to be that someone can't use an authenticator that follows the standard protocol but is made by a different vendor? The only thing the attestation actually does is make it so that you can't use e.g. GrapheneOS instead of Android, which has a tenuous relationship to being a legitimate prohibition.

To pick a boring example: you run IT at a big company. You want all your employees using passkey auth, and you want it to be smooth for them, so you buy a bulk order of a couple thousand yubikeys and some glass fishbowls and plop a fishbowl full of yubikeys in the middle of each office.

Attestation means you can trust that nobody is accidentally or intentionally enrolling some random passkey-presenting device with rogue components.

We just had a front page story here this week about folks buying what they thought were secure hardware cryptocurrency wallets that had been modified maliciously.

That's the scenario where you need it the least, because then you're providing the devices and can register the key of each of the yubikeys before you drop it in the fishbowl. Then if someone throws a handful of rogue sticks into the fishbowl, their keys aren't on the list.

Which would further impede the scenario where they have the capability to extract the key from a real yubikey and then throw some of those in the fishbowl, because then even though they're "real" they're not on the list. To pull that off when you're enumerating the keys instead of using remote attestation they would have to go to the office and grab a handful of keys, hope nobody notices that that many of them have disappeared, extract the keys from them and hope they don't destroy any of them in the process since they can't replace them, and then go back to the office to put them back in and have a second chance of getting caught. Whereas with remote attestation they go buy a bunch of yubikeys, break as many as they need to in order to extract the private keys from some of them, then show up once to exchange those for the same number out of the fishbowl since you're only verifying "is a yubikey" rather than "is one of ours".

You also don't need remote attestation to verify that the keys you bought are the expected model, because a key that can establish that can do it locally when you're registering it without involvement from the network authentication protocol.

All the rest of this argument just misses me. Whatever the non-phishable authentication you want to use is, that's fine by me. But TOTP is phishable, eminently so, so you're not going to see security people back down from deprecating it.

Then they need to advance an alternative that doesn't support remote attestation.

I think the arguments about attestation are bogus for all the reasons everyone else is pointing out but that doesn't matter because I'm not talking about Passkeys, I'm talking about why TOTP is a dead letter. You're not going to get security people to back down on deprecating TOTP, because it's phishable, and the point of modern authentication protocols is defeat that attack.

By all means, keep lobbying against Passkeys! I don't care. But you'd be shooting yourself in the foot rhetorically to build TOTP into your case, as the comment I replied to originally just did.

Reply on news.ycombinator.com