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

@emlun 
>I can currently think of only one workaround that'll work with no spec or implementation changes: require attestation, and only allow authenticators that are known to not support the hybrid transport (i.e., only built-in, USB and NFC).

I tested it with a Security Key on Android and it worked. So it works also with authenticators that are known to **not** support the hybrid transport (see https://denniskniep.github.io/posts/14-fido-cross-device-phishing/#security-keys-also-affected)


>But yeah, I don't think we could add any signed attribute in WebAuthn that would make the attack preventable or detectable, since the attacker completely sidesteps WebAuthn and is in full control of what's being signed.

As you said this attack acts as CTAP client and is in full control what he sends to the Authenticator (e.g. origin). The Authenticator receives the crafted CTAP messages. But this attack is not in control of the Authenticator on the other side of the TunnelServer. 

Maybe the CTAP client is not directly connected to the final Authenticator. It could be that there is e.g. an OS Credential "Router" (does this has an official name?) in between. I guess that is what @timcappalli was referring to:

>That is only the case for traditional authenticators using external transports (USB, NFC, Bluetooth), not for software-based credential managers.

Example 1: Directly connected
```
.get() --webAuthnReq---> [CTAP Client] --CTAP Msg--> [TunnelServer] --CTAP Msg--> [Authenticator]
```

Example 2: OS Credential "Router" 
```
.get() --webAuthnReq---> [CTAP Client] --CTAP Msg--> [TunnelServer] --CTAP Msg--> [OS Credential "Router"] --CTAP Msg-->  [Authenticator]
```

Because this attack can not control the execution of the components on the other end of the Tunnel Server, we might be able to leverage that situation to better secure that scenario. 

What if the listener that is connected to the TunnelServer (e.g. OS Credential "Router" or Authenticator - see above examples) are adding to the CTAP message flow a signal that `hybrid` was used. 
This signal will then be part of the signature e.g. as proposed here by @LBBO 

>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)?

Now the webAuthnResponse contains a verifiable proof that `hybrid` was used, independent of the actually used Authenticator.
The RelyingParty is now able to reject the authentication.






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


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

Received on Friday, 24 October 2025 22:52:34 UTC