- From: Matthew Miller via GitHub <sysbot+gh@w3.org>
- Date: Sun, 23 Jan 2022 16:03: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): https://www.w3.org/TR/webauthn-2/#credential-key-pair > A credential private key is the private key portion of a credential key pair. The credential private key is **bound** to a particular authenticator - its managing authenticator - and is expected to never be exposed to any other party, not even to the owner of the authenticator. https://www.w3.org/TR/webauthn-2/#public-key-credential-source > The authenticatorMakeCredential operation creates a public key credential source **bound** to a managing authenticator and returns the credential public key associated with its credential private key. The Relying Party can use this credential public key to verify the authentication assertions created by this public key credential source. https://www.w3.org/TR/webauthn-2/#bound-credential > A public key credential source or public key credential is said to be **bound to its managing authenticator**. This means that only the managing authenticator can generate assertions for the public key credential sources bound to it. Security models have been evaluated and approved with the fundamental assumption that private keys never leave the authenticators. Now passkeys come into the mix offering huge wins for account recovery, but fundamentally break the numerous assertions in L2 that key pairs will "never be exposed to any other party, not even to the owner of the authenticator." Accounting for passkeys requires RPs to now audit their existing security models to understand the impact of the account security protections "platform vendors" implement to protect their cloud sync accounts handling private key syncing. 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`. Suddenly changing fundamental assumptions about its WebAuthn's usage damages the API's reputation if we don't also offer a way to revert its usage to pre-passkey, device-bound functionality for existing implementations. `devicePubKey` will be the spec's way of **preserving backwards compatibility**; without it influential RP's may abandon WebAuthn and never look back, having longer-term impact on API credibility than intended. -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1019514936 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 16:03:15 UTC