- From: Firstyear via GitHub <sysbot+gh@w3.org>
- Date: Sun, 23 Jan 2022 23:20:14 +0000
- To: public-webauthn@w3.org
> > Multi-device WebAuthn credentials is synced with cloud of a party, e.g., a platform vendor, whose cloud security is not known to RPs. So some RPs cannot accept such cloud synced multi-device WebAuthn credentials, despite the convenience that it offers. For them, devicePubKey is the mechanism not to accept cloud synced multi-device WebAuthn credentials with unknown security unconditionally, but to accept them after their own verification to ensure the security of the RP's accounts. > I actually agree with @maxhata on this issue. Until passkeys WebAuthn usage _always_ generated device-bound credentials. The spec states as such in several places (emphases mine): ``` All WebAuthn Extensions are OPTIONAL for both clients and authenticators. Thus, any extensions requested by a Relying Party MAY be ignored by the client browser or OS and not passed to the authenticator at all, or they MAY be ignored by the authenticator. Ignoring an extension is never considered a failure in WebAuthn API processing, so when Relying Parties include extensions with any API calls, they MUST be prepared to handle cases where some or all of those extensions are ignored. ``` Generally the way webauthn is designed, as the RP you have very little influence here since extensions are OPTIONAL, and any browser javascript, or the browser could strip the extension requests away with out you knowing. How do you plan to detect this case? Second, you now already have a large number of devices in the wild that have passkey functionality that may not be updated to also support dpk. Third, there is no flag that says if a credential that was created is a passkey credential or not. So as an RP you can't actually validate that passkey is combined with dpk anyway. Fourth, how are you planning to "go back in time" to check that any historically registered credential wasn't a passkey credential? > Consider the following scenario with passkeys: > > > A user with a Google account get phished because they never sets up 2FA on their Google account. The attacker logs into the user's account on an attacker-controlled device and authenticates as the user on the RP's site. > > An RP assuming device-bound credentials has no defense against this without the `devicePubKey` extension. Is the Working Group's advice to RP's about this, "whoops, deal with it"? Because I can't think of what we'd propose as a short-term fix to defend against this without the availability of `devicePubKey`. And at the point someone has access to my google, they have my email and can reset all my account passwords anyway. So what is this really defending from? The flaw here is not in webauthn - but RP's. RP's have made it *so difficult* to support multiple devices on their accounts, that it's easier to sync webauthn keys on a vendor device, than to both trying to convince github/twitter/others to actually implement proper UX/UI. I think there are huge wide holes in this whole scheme, and webauthn can't plug them because it was never designed in a way to allow such strict RP guarantees about what authenticators are used. -- GitHub Notification of comment by Firstyear Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1019589729 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 23 January 2022 23:20:16 UTC