Re: [webauthn] Hybrid transport opt-out and ability for verifiable proof (#2349)

> To me this _feels_ different than a compromised client. I understand that most bets are off if there's malware running on the victim's client. But in this scenario, the victim's client is completely uncompromised.

Yeah, I agree we can't simply dismiss this with "compromised client is outside the threat model". The only thing the victim does wrong in this scenario is use a benevolent client to visit a malicious website - exactly the scenario that WebAuthn's phishing protection is meant to address.

> Yeah, I guess modifying `clientDataJSON` wouldn't work. But since the authenticator knows how it's communicating with the client, couldn't it add that information to its response (e.g. by using one or more of the reserved flags in authenticatorData)?

Hm, yeah, the authenticator definitely _could_ add signals like this. Using an `authenticatorData` flag for this seems disproportionate, but it's definitely possible to add this data as an authenticator extension. That wouldn't help at all for any currently existing non-upgradable security keys, though.

Either way, I don't think that just adding a detection mechanism is the right way to go. The proper solution should be to either eliminate the vulnerability from the transport, or drop the transport altogether. Because that would be the use for the detection anyway, right?: forbid the `hybrid` transport altogether on the RP side, since the RP doesn't know whether or not it was used maliciously. Any existing RP implementations that don't update to check the new detection mechanism get no benefit, so their users are still susceptible to the attack. Conversely, if the vulnerability _does_ get fixed, then users would remain unable to use the `hybrid` transport until RPs update their implementations to no longer forbid it. And finally: even newly manufactured security keys wouldn't have any idea about being proxied over `hybrid` unless the proxying platform adds a hint about that in its input to the authenticator - so then we're modifying the `hybrid` protocol anyway, so we might as well address the vulnerability directly instead.

So a detection signal seems like a very unwieldy solution for a problem that will hopefully end up being temporary. Ideally it should be enough for the user to update their client (and possibly smartphone OS) to get whatever countermeasure we end up with.

Unfortunately I think all of that also means (if we assume that my assessment and opinion is objectively correct 😇) that we can't feasibly expect much visibility for RPs to tell once a fix has been rolled out, either. We can't update existing security keys, so we can't assume a signal from the authenticator. We could bundle a transport fix with a `clientDataJSON` attribute that signals the client is using some new `hybrid` protocol version that fixes the issue (and an attacker couldn't lie about this attribute because the new protocol wouldn't give the attacker an opportunity to connect to the authenticator), but then that signal would of course only be present when the issue is fixed, so the RP could only differentiate between "not vulnerable (used non-`hybrid` transport or fixed `hybrid`)" and "maybe vulnerable (used non-`hybrid` transport or vulnerable `hybrid`)", which doesn't help much.

So yeah, I think that even just adding a signal for detecting the `hybrid` transport would still effectively require changes to the `hybrid` protocol, so to me it doesn't seem very useful to look for mitigations other than just eliminating the vulnerability in the first place.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2349#issuecomment-3451433067 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 27 October 2025 13:58:46 UTC