W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

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

From: Firstyear via GitHub <sysbot+gh@w3.org>
Date: Mon, 24 Jan 2022 22:40:00 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1020622203-1643063998-sysbot+gh@w3.org>

> Yes, although the can of worms has been open ever since the move from U2F to WebAuthn made attestations optional.
> 

For the majority of RP's, attestations are useless noise since how can you trust or keep up with which vendors are good vs not. Even reading the spec it's obvious that attestations are pretty much for some limited major enterprises who want to strictly control hardware supply chains, and it's pointless to other RP's. 

> That created two tiers of relying party implementations, and it sounds like there are assumptions that the 'no attestations' tier had assumed security properties.

The webauthn specification miscommunicates it's properties allowing RP's to easily misinterpret what is a security property and what is not. And apparently no one seems to care ...

> We also should also clearly state for relying parties that any information given without attestations are advisory, e.g. they don't strongly state security properties. This may justify fewer, broader signals for non-attested use.

Attestations only provide a statement about the *origin* of the authenticator, not it's PROPERTIES that it does or does not support. So far the WG has tried to hamfist this in through extensions (see credProps, credProtect), but of course the issue is that extensions are optional and there is no way to distinguish JS tampering due to compromised site vs the authenticator not supporting the extension. 

Which is why we are in this mess, because there is no way with DPK + Passkey to actually connect the properties of the credential that are desired here. We have a world in which Passkey now exists, and there is no way for an RP to discover that, and you can't retrofit that, because you can't assume anything about the credentials that have already been registered (since the webauthn spec pretty much tells all RP's to discard everything but the public key and that's insufficient to trace back to attestation/extensions/other). 

To make this even spicier, even if webauthn says "Oh it's a requirement you must flag if your public key is a passkey", it won't matter since you rely on vendors to implement that correctly, or to implement it at all. And if RP's start deny-listing or messing with credentials just because they are passkey backed, why would a vendor flag their keys in this way? 

Look at the DPK proposal, the whole point is to just signal that something *is* a passkey, but it doesn't prevent a passkey implementor from you know ... just lying about if it's passkey or not. 

> @MasterKale please explain how multi-device WebAuthn credentials now allow a user to be phished. These are dangerous statements to casually make without an explanation.

@timcappalli If the passkey is synced with a cloud provider, then access to the cloud account allows downloading and retrieval of the passkey. So if the cloud provider account is phished, then the passkey can be retrieved.  Thus the phish occurs on the cloud account, not between webauthn and the RP. It's phishing to credential theft. 



-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1691#issuecomment-1020622203 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 22:40:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:44 UTC