- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Sep 2023 14:07:17 +0000
- To: public-webauthn@w3.org
If I understand the described attack correctly: 1. The attacker performs a **script injection attack on themself** in order to extract the `PublicKeyCredentialRequestOptions` parameters, 2. The attacker sends these `PublicKeyCredentialRequestOptions` parameters to a trojan running on the victim's machine, 3. The victim **interacts with the trojan** in order to produce an assertion response, 4. The trojan sends the assertion response back to the attacker, and 5. The attacker assembles the `PublicKeyCredential` result and presents this to the Relying Party, thus successfully impersonating the victim. Then this is not a vulnerability in the WebAuthn API, because the attack in fact works by _circumventing_ the web platform on the side of the victim, thus bypassing the protections specified in WebAuthn. As also [noted](https://github.com/w3c/webauthn/issues/1965#issuecomment-1723019532), it's not even necessary for the attacker to involve the web platform at all on their side either. I conclude that this attack is off topic for the WebAuthn spec. This is not to say that the described attack wouldn't _work_ - assuming the attacker can successfully plant the trojan and get the victim to interact with it - but it's nothing we can fix in the WebAuthn spec. The security guarantees depend on the user interacting with a [conforming user agent](https://w3c.github.io/webauthn/#conforming-user-agent), which a malicious trojan is clearly not. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1965#issuecomment-1739298051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 September 2023 14:07:19 UTC