Re: [webauthn] devciePubKey extension MUST be supported if passkey is supported (#1691)

> Your points about extensions being optional and easy for browsers or authenticators to ignore (or be incapable of supporting) is a valid one. I don't know what a path forward is now...tell RP's to let passkeys happen and forget about `devicePubKey` since it can't reliably achieve its intended goal of supporting pre-passkey operation before passkeys deploy?

What we can and likely should say is that authenticators should not change security properties of credentials they have already issued, e.g. a public key credential issued in the past bound to one device should not attempt to get upgraded to passkeys.

For platform-based authenticators, this would mean putting thought into the process of relying parties having the end user migrate to the platform authenticator which implements passkeys - e.g. whether that means vendors are encouraged to have a 'grace period' where the old public key credentials work and so on.

This may be useful in other cases, such as browsers that implemented their own support for built-in authenticators in lieu of existing platform-level support.

It is really important to keep in mind that there is no 'pre passkey' behavior. The way some vendors are now looking to structure their authenticators has always been valid. I think a lot of people had preconceptions of how much they could assume about the security properties of authenticators before their implementations needed to handle attestations to attempt to prove those assumptions (spoiler: not much can be assumed)

A (rough, likely terrible) analogy: non-attested WebAuthn is like letting the user pick their own password. Checking AAGUID is at most like a simplistic complexity check. Attestations are like breach list checks.

> > 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?
> 
> I think this highlights a flaw in passkeys: that now there is an avenue to phish users when originally the spec made WebAuthn-based authentication phishing resistant. Is that trade off worth it for an actual account recovery story for the consumer market?

I don't think this is a phishing vulnerability but an account compromise one, but this thought leads to what I suspect is the core issue - the mental model of WebAuthn as being technology to talk to key fobs (or WebAuthn as key fob functionality embedded into a laptop or mobile phone) wasn't totally accurate, because people conflated that with some set of minimum security properties. If a RP wants to require the security properties there, they need more logic including attestations.

Without attestations, relying parties have no way to guarantee the device bound credential has appropriate security properties either. Maybe if the clients got into the business of enforcing some third-party conformance via deny lists themselves.

I don't think we get to say whether that trade-off is worth it; users will be compelled to use less secure authenticators. We also haven't been able to  keep users from reusing the same password on every website that will accept it. Attestations are arguably a much more solid way to know the 'quality' of the credential than breach lists, however.

I know it's unfortunate, because supporting attestations is a real pain both in terms of complexity and maintenance. It just isn't a new reality.

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


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

Received on Monday, 24 January 2022 16:03:45 UTC