- From: Joost van Dijk via GitHub <noreply@w3.org>
- Date: Tue, 28 Oct 2025 08:58:43 +0000
- To: public-webauthn@w3.org
> There's a similar class of vulnerabilities (assuming you have a bluetooth beacon in place) for classic bluetooth authenticators. I think in that case you might be able to get away with attestation to reject those because there's no forwarding for classic bluetooth the way it exists for hybrid. I was incorrectly assuming there was no forwarding of CTAP messages from hybrid transport to usb transport on Android either. @nsatragno Has that always been the case or is that a recent addition? And am I correct that this is a feature of Google Password Manager? Given the following obervations (please correct me where I'm wrong): - Hybrid flow has been introduced to enable platform authenticators to be used cross-device. - The attack described here is not new (see for instance @agl's excellent [Tour of WebAuthn](https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html#hybrid-transport), section "Threats"), instead hybrid flow was designed to sacrifice a bit of security for increased usability. In other words: FIDO credentials are still phishing-resistant, but hybrid flow introduces a small attack vector that can only be launched from within the vicinity of a victim (as opposed to the whole of the Internet with traditional passwords) - Security keys do not need the hybrid flow, as they are designed to be used cross-device. Would it make sense to disable the use of security keys when using hybrid transport, as there is no strong use-case for it? -- GitHub Notification of comment by joostd Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2349#issuecomment-3455289062 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 28 October 2025 08:58:44 UTC