search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.18k stars 172 forks source link

devicePubKey extension MUST be supported if multi-device WebAuthn credentials are used #1691

Closed maxhata closed 2 years ago

maxhata commented 2 years ago

I do not know if this issue has been discussed already. Since it is an important issue for RPs, please allow me to file this issue.

If passkeys (or cloud sync credentials) is supported, devicePubKey extension MUST be supported.

There are many RPs who cannot accept passkeys without devicePubKey due to security and/or legal reasons. If there is a device that supports passkeys but not devicePubKey, such RPs cannot deploy WebAuthN or FIDO at all.

sbweeden commented 2 years ago

Should it also be the case that attestation AAGUID for passkeys be unique and distinct from a device bound credential created on the same platform authenticator? Said another way, the RP, when using attestation, should be able to determine if the credential created by a platform authenticator is a passkey even if the extension is not requested or otherwise absent.

maxhata commented 2 years ago

It sounds similar and helpful. But I do not think it addresses my problem.

If RPs know a phone with AAGUID=X supports passkeys but not devicePubKey extension, RPs can exclude passkeys from all the phones with with AAGUID=X. If 10 million customers of a RP are using the phones with AAGUID=X, the RP cannot enable webauthn for all the 10 million customers. This will be a big problem for their businesses.

If the phone supports passkeys and devicePubKey extenstion, RPs can enable webAuthn for the 10 million customers using devicePubKey extension if the reason is mainly due to security of passkeys.

So I think unique AAGUID will help RPs but not quite address my problem.

RPs want to find if a credential is a cloud synced credential or not when they receive one. I wonder if unique AAGUID may help solve that problem?

arshadnoor commented 2 years ago

I do not believe a separate AAGUID is necessary for Passkey-like solutions (where the private-key and credential are portable across devices); there is an easier solution available within the protocol.

I recommend that one of the bits in authenticatorData - say, Bit 3 - be used to indicate that the credential with its private-key is portable across devices/authenticators. If Bit 3 is set, the credential and its private-key are portable across devices; if it is NOT set, the credential and its private-key are bound to the device on which the key-pair was generated.

Regardless of AAGUID, an RP will be able to determine, at registration time, whether the credential and its private-key are device-bound or portable. This is easier and faster than having to process an extension (which will also carry additional baggage in the registration response from the authenticator).

timcappalli commented 2 years ago

A couple of things:

With all that being said, we are considering a mechanism to allow the authenticator to convey whether a credential is "durable" (e.g. you are safe to migrate the user away from a password or other methods) and potentially also whether the credential is allowed to move across devices. For example, you could have a credential that is allowed to move across devices, but it still remains on only one device, so it is not yet "durable".

maxhata commented 2 years ago

Thanks for all the comments.

I not know the best way to define the requirement in the spec. But RP requirement is how to avoid the following situation.

There are many RPs who cannot accept passkeys without devicePubKey due to security and/or legal reasons. If there is a device that supports passkeys but not devicePubKey, such RPs cannot deploy WebAuthN or FIDO at all.

How will this be avoided? How can the WebAuthN spec help solve?

timcappalli commented 2 years ago

@maxhata I'm not following this statement:

If there is a device that supports passkeys but not devicePubKey, such RPs cannot deploy WebAuthN or FIDO at all.

An RP can still continue using security keys (single-device passkeys) as well as platform authenticators that support single-device passkeys.

dwaite commented 2 years ago

To further elaborate on what Tim said:

WebAuthn (and AFAICT CTAP 2.1) do not define Authenticators as being implemented via hardware/devices, but rather as a more abstract concept. Credentials also aren't stated as being bound to hardware/devices - they are bound to an authenticator.

There have been conversations as well about the possibility of exportable credentials, which would require spec changes and be a new thing. However, an authenticator which is defined in terms of cloud hosting rather than encrypted flash storage is still an authenticator.

Passkeys, AFAIK, are an Apple product initiative name. A catchy name for sure, but we do not necessarily know what features this name means, or even if all of those features are within WebAuthn (or CTAP).

So there has been a bit of a struggle. Some have been struggling to find a descriptive name that describes what is coming, before we have consensus on which feature is meant to be inside the box. Others have been using a vendor term to describe what is inside the box, without a clear commitment to what will be shipped.

All that said:

Even if the specifications made hardware binding a MUST, a RP cannot tell from the assertions whether or not the credentials are within a trust zone of a non-upgradable, FIPS-compliant hardware key or are a lookup of a HTML table on the front page of some web domain. It cannot tell from an AAGUID whether it is dealing with a genuine product or someone who saw that key in debug logs and added it to their toy USB key project or Web Extension.

Policy decisions MUST stem from attestations, and the vendor guarantees or industry certifications which back them. There is simply no other technological measure to securely verify you are dealing with something meeting your policy, vs. say a Web Extension someone whipped up that sorta kinda behaves like a particular vendor's keys.

The problem statement is not that relying parties are going to start accepting authenticators that no longer meet their policy.

The problem statement is that a certain variety of authenticators need additional capabilities because otherwise, certain relying parties are not going to accept them. Relying parties then need to decide whether they want to leverage those capabilities in order to be able to accept those authenticators.

dwaite commented 2 years ago

How will this be avoided? How can the WebAuthN spec help solve?

The relying parties will use attestations, gathered at credential registration time, to make a decision on whether or not to accept an authenticator.

If an authenticator is implemented in a way their policy cannot accept, such as having an authenticator defined to use cloud hosting and synchronization rather than encrypted flash storage, the relying party will tell the user to register a different authenticator, possibly providing a list or instructions on how to get a supported cross-platform hardware fob.

If the authenticator might meet policy if certain extensions were used, like devicePubKey, the relying party will have to decide if they are willing to do the implementation work of supporting those extensions. An implementation of devicePubKey arguably requires a risk-aware authentication system and authentication flows.

If an existing software authenticator changes their implementation, such that existing issued credentials no longer have the same security properties as before, the relying party may stop accepting credentials from that authenticator and potentially revoke existing ones. The relying party would tell users that they must use another form of authentication or go through account recovery. Most would say that this would be a very poor business decision from an authenticator vendor.

For the 90%+ of relying parties that don't care, don't have acceptable authenticator policy, and don't ask for attestations, they will do absolutely nothing.

MasterKale commented 2 years ago

Passkeys, AFAIK, are an Apple product initiative name. A catchy name for sure, but we do not necessarily know what features this name means, or even if all of those features are within WebAuthn (or CTAP).

To provide some insight to this part of the conversation "passkey" is intended to be a platform agnostic synonym for "FIDO credential". Apple passkeys, Android passkeys, and Microsoft passkeys - they'll all refer to the same kind of discoverable credential, only differing by which platform vendor is responsible for syncing them to the cloud. Otherwise for the purposes of WebAuthn they're typical credentials we all know and love.

dwaite commented 2 years ago

To provide some insight to this part of the conversation "passkey" is intended to be a platform agnostic synonym for "FIDO credential". Apple passkeys, Android passkeys, and Microsoft passkeys - they'll all refer to the same kind of discoverable credential, only differing by which platform vendor is responsible for syncing them to the cloud. Otherwise for the purposes of WebAuthn they're typical credentials we all know and love.

That is cool, I had not heard that initiative.

I've heard PassKeys being used across contexts to describe some mix of cloud-synchronized authenticators, exportable credentials, conditional mediation, and the overarching UX. Someone should pin down a definition publicly - even the one you gave made me ask "wait, what's a FIDO credential?"

MasterKale commented 2 years ago

Someone should pin down a definition publicly - even the one you gave made me ask "wait, what's a FIDO credential?"

I understand "FIDO credential" as the "technical" term for a WebAuthn credential. Sorry, I didn't mean to complicate things in a different direction 😂

As to a specific definition for the general public I imagine we'll get something sooner than later, especially confirming the name as "passkey", all lowercase 😛

ve7jtb commented 2 years ago

I think the whitepaper that Dirk has been editing in the Fido2 TWG now defines passkey as a synonym for a Fido credential.

That probably should be a CTAP1 or CTAP2 Fido credential to be precise as there are still UAF Fido credentials that would not be covered.

Given that platform authenticators from Apple and Microsoft make all credentials as discoverable (I expect that Android will as well at some point) it may be easy to forget that passkeys should also include non discoverable credentials. from existing authenticators. Non Discoverable credentials may also have the property of being multi device. Alexei from Google proposed several ways that could be done several years ago now.

I admit that in the proposed new UI flow non-discoverable credentials are less useful, but that should be a separate issue from credential backup/syncing.

I expect that we will have RP with a range of usecases 1 want to be able to remove all passwords multi-device in some synced state is required, may reject single device credentials 2 Don't care will take anything, won't bother with attestation Probably 80% 3 Will take single and multi-device credentials but will require the devicePublicKey extension for high risk transactions.
4 High risk Will always require attestation require single device only or multidevice with known devicePublicKey

3 will probably be the most complicated for the RP. We are a long way from having out of the box solutions for that at the moment.

The idea of reusing some of the unused bits in the assertion is interesting.
We would however need to take 2 bits. 1 Single Device 0 / multi-device capable 1 2 Not backed up 0 / backed up 1

Conveniently current authenticators setting 00 would be the correct thing by default.

I think we have two undefined bits but would need to double-check.

That could also be an extension but then the RP needs to ask each time. It may be possible some platforms might toggle state between backed up and not depending on if the user has multiple devices or other factors. Probably only sophisticated RP would look at it ongoing in the assertion but I think it should be included.

That could also all be a separate extension if we want to give RP the option of asking for it or not. I sort of prefer to always return the info even if it is not solicited, I think that is cleaner.
The other problem with extensions is that they have a longer lead time for platform API to implement, but I could go either way.

I don't like having multiple AAGUIDS that is nasty, I have put the most entries in the MDS, so have some experience.

A single AAGUID for the authenticator that has appropriate flags in the assertion and makeCredential response is a better way to go.

The other thing to consider is that WebAuthn really has no say in how the authenticators behave. That would be the Fido2 TWG and the Fido SPWG who would define what extensions would be mandatory for Fido certified authenticators.

Assuming that Authenticators that support multi-device passkeys can get Fido level 1 certified then it would be up to one for both of those groups to say that certain bit flags or extensions need to be supported for certification.

A current example of that is the security requirements require the credprotect extension be supported in any authenticator that supports discoverable credentials (Unless only level 3 is supported or UV is always done)

I would leave it to the Fido SPWG to define the certification requirements and not try to add it to the WebAuthn specification where it would not really be validated in implementations.

dwaite commented 2 years ago
  1. want to be able to remove all passwords multi-device in some synced state is required, may reject single device credentials
> 1 Single Device 0 / multi-device capable 1 > 2 Not backed up 0 / backed up 1 The use case of a less-sophisticated RP requesting authenticators which are backed up due them lacking sophisticated/cost-effective account recovery flows is interesting, as that is one where attestations and extensions adding more sophistication really wouldn't help. I don't know if this would be more of a client request (which could be accomplished via authenticator metadata) or something where there's value in having the authenticator self-attest the current backup state of a credential.
MasterKale commented 2 years ago

...it may be easy to forget that passkeys should also include non discoverable credentials. from existing authenticators. Non Discoverable credentials may also have the property of being multi device.

The way the conversation went in the last FIDO TWG meeting, "passkey" will refer to cloud-synced discoverable credentials that can be used across devices. The differentiated "single-device passkey" can be used instead to refer to existing credentials, credentials generated on security keys (or other authenticators without cloud syncing capabilities), and credentials with device-bound public keys generated with the upcoming devicePubKey extension.

timcappalli commented 2 years ago

Since this is a discussion about the WebAuthn spec, as I suggested before, let's just simply use "multi-device WebAuthn credential" or "single-device WebAuthn credential". Whether it is "synced" or not is irrelevant.

Let's also reign this specific issue back in to discussing DPK being required.

dwaite commented 2 years ago

I would argue it is a lot of work for likely zero reward.

Authenticators today are defined by their behavior at their boundaries, not by the shape of their box. That means someone who disagrees with such a mandate will just stick to level 1 or 2, or implement level 3 without implementing that one piece. The only way you can actually tell from a relying party if an authenticator implemented level 3 correctly is via attestations.

Attempting to mandate such implementation requirements also opens the group up to a lot of new work defining the shapes of those boxes based on suspected relying party policy logic. Today, devicePublicKey and that it is dealing with 'devices' and 'hardware' are easier definitions to set, because they are both opt-in and settling on whether an authenticator is implementing the extension correctly is a matter of conformance.

As an example of the sort of challenges that pulling implementation details into working group responsibility causes, note that the current proposal for the extension has a scope value because vendors wishing to support this couldn't agree on whether it was bound to a hardware installation or to individual applications living on that hardware. I continue to argue that scope so far has no purpose from a risk system value, because such information should be gathered via attestation (also, I can't imagine what use knowing something is application-bound is when you can't detect you are on the same platform or not)

The reality is that 'hardware' is made up of many components, and whether the private material of a public key credential can be extracted with a firmware update, a soldering iron or an electron microscope is not worthwhile without certification and attestations of conformance, which are not in this group's scope except for the mechanism we already have for securely conveying them - attestations.

That logic gets even more complex once you look at the device-bound public key as part of a risk engine. Different relying parties actually care about different things, as we've seen with other protocol additions like enterprise attestations.

A risk analysis product could be argued to likely want to take into account the process of provisioning the other devices and their general product security. One could imagine hardware factory-set and sold in pairs which allowed for backup and recovery, but no additional keys to ever be minted. On the other hand, one could imagine an authenticator where the keys are stored insecurely in the cloud and fully recovered via a single factor.

A primary reason for this extension is for input into a risk system. Implementation details like this would drastically alter the perceived strength of the credential and thus how much work is needed to accept it. The only way a risk system can make decisions like this is via attestations.

maxhata commented 2 years ago

An RP can still continue using security keys (single-device passkeys) as well as platform authenticators that support single- device passkeys.

No.

For consumer use cases, security keys are difficult to address millions of consumers. RPs want to use smartphones for many consumer use cases. RPs are already deploying webauthn with smartphones for many consumer use cases. Some of them already have tens of millions smartphones supporting it -- actually we are one of them.

But some of these RPs cannot accept passkeys or "multi-device WebAuthn credential" without devicePubKey due to security reasons. For example, some of their consumer accounts are linked with each customers' bank accounts to enable them to do financial transactions. This model is already working very well with many RPs that have already deployed webauthn with smartphones such as iPhone and Android.

If a device that generates passkeys or "multi-device WebAuthn credential" but not supports devicePubKey, then these RPs have no choice but to give up deploying WebAuthn. This is the reason.

maxhata commented 2 years ago

devciePubKey extension MUST be supported if passkey is supported.

What I mean is "if a platform is supporting multi-device WebAuthn credentials (or passkeys), the platform MUST support deviePubKey extension.

Assuming multi-device WebAuthn credentials will be provided by platform authenticators by respective platform vendors.

The reason is stated in my comments above.

maxhata commented 2 years ago

Multi-device WebAuthn credentials that are syncable and devicePubKey extension are an inseparable pair, where devicePubKey extension is a fallback.

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.

MasterKale commented 2 years ago

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.

dwaite commented 2 years ago

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.

To an authenticator, which in this case is software with cloud storage.

Whether it is software with cloud storage or a USB key or local platform TPM only is only really determinable to the relying party via attestations. Without platforms/browsers taking position on what implementation details are required and doing a vendor deny list, the ability to determine if an implementation meets such a requirement is via manufacturer-asserted or certification-body-asserted attestations.

Directly issuing certification requirements is something which we have not done so far, and is a different ‘type’ of work IMHO better left to other groups when possible.

Firstyear commented 2 years ago

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.

MasterKale commented 2 years ago

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?

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?

Firstyear commented 2 years ago

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?

Pretty much. IMO the ship has sailed. We live in a world where passkey will become common.

Regardless, any proposal like this needs to not only demonstrate "how passkey + dpk can be enforced" but also the inverse - how it can be correctly asserted that a non-passkey credential, or a passkey credential without dpk can be asserted. If you can not demonstrate these three combinations, the suggestion is already flawed.

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?

Given that almost every single RP in the world has amazingly failed at multi-device authentication considerations, yes it is necessary.

To drive this home, let's consider I want to use my ipad with an RP for example. Pretty much every RP today has a story like this, so I won't bother naming one. Assume I have password + webauthn configured. But the webauthn authenticator is a yubico 5c nano. That can not connect to my ipad.

As a result to add my account to my ipad I must:

  1. Configure TOTP (likely on a phone with freeotp as an app) on my RP account
  2. Send the password (long, machine generated) to my ipad via some out of band means (perhaps signal note to self, icloud notes sync, or icloud keychain. Who knows)
  3. Login by copy-pasting the password, and then typing out the TOTP from my phone into the ipad
  4. Go to my account settings
  5. Copy-paste the password again to access my account settings to re-validate it's me
  6. Enroll my ipad touch id as a webauthn device.
  7. Remove TOTP from my account and freeotp.

This is the workflow most RP's provide. It's horrible. It's unfriendly. It has weaknesses everywhere.

So of course passkey and device sync was the inevitable outcome, especially from a company that has a focus on usability like Apple. RP's still demand a password, and they make adding another device painful. Apple Keychain sync and passkey sync makes this painless to move between your devices in a way that RP's have failed to consider.

ve7jtb commented 2 years ago

I agree that authenticators that support multi device web authn credentials should support dpk. However, WebAuthn is not the place to enforce that. WebAuthn is a browser API and not an authenticator specification. We have a grey area because it is possible to define WebAuthn extensions that CTAP2 authenticators may support.

Nothing can be trusted from an RP perspective without some trusted attestation. The proper place to define this is the Fido SPWG. That is where the requirement to implement dpk or other extensions can be generally enforced and published in meta-data for RP.

I am not particularly concerned about the big 3 platform authenticators they will support dpk and be certified or have a large enough base that RP will hard code their attestations and make decisions to trust them or not.

The certification requirement is mostly for all the other authenticators that will implement multi-device strategies to compete in the consumer market. We are opening a can of worms here for more than just platform authenticators.

I do think we need something separate from dpk as well to indicate if a credential is multi device and if it has been backed up/ durable or whatever we are going to call it.

dpk is in itself not a sufficient flag, nothing will stop authenticators that are not multi device from also supporting dpk, and even if they are multi device capable that dosen;t mean that the credential is backed up.

At the end of the day one of our goals in the consumer space is to allow RP to remove passwords as an authentication method.

timcappalli commented 2 years ago

that now there is an avenue to phish users when originally the spec made WebAuthn-based authentication phishing resistant.

@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 commented 2 years ago

I agree with @ve7jtb that any discussion around security properties should happen in FIDO Alliance - SPWG.

There have also been multiple mentions of extensions being optional. The only real next step that can happen for this discussion is a potential proposal (in a new issue) to remove the spec text around extensions being optional. FTR, I don't support this.

emlun commented 2 years ago

So to summarize some of the main points in this thread:

Without attestation, there are NO guarantees about how the authenticator works.

This has always been true, always will be, and passkeys will not change this fundamental fact. If an RP has some opinion that some authenticators, or authenticator features, are acceptable and some are not, the only way to enforce that is through attestation. As stated in §6.5. Attestation (emphasis mine):

If an authenticator employs self attestation or no attestation, then no provenance information is provided for the Relying Party to base a trust decision on. In these cases, the authenticator provides no guarantees about its operation to the Relying Party.

Of course, if an RP does not actively enforce attestation requirements, then this is equivalent to the above scenario.

So if an RP has implemented WebAuthn without collecting and validating attestation statements, and its security posture would be undermined by the introduction if multi-device passkeys, then that RP has unfortunately based its implementation on incorrect assumptions. That RP would have to start collecting and validating attestation statements, and revoke any existing credentials that don't satisfy the RP's requirements. There's nothing we can do from a spec standpoint to help or change that, but maybe we could somehow point all of this out more clearly to the reader.

arshadnoor commented 2 years ago

I appreciate that folks on this list are starting to see what FIDO is all about (security). That FIDO made some complex things easy, was truly a bonus.

In the past, I have cautioned against going down the road PKI traveled; but I never imagined that FIDO ("Simpler, stronger authentication!") might choose to surpass PKI in complexity. The "Cloud" is primarily responsible for this, IMO. But, what is ironical is that the company that gave the world its iconic "1984 https://duckduckgo.com/?q=apple's+1984+ad" ad is the one that opened up this Pandora's Box!

Truth is, indeed, stranger than fiction.

I will continue to advocate for what I believe is the only sustainable FIDO solution: delivering the core FIDO security capability, and educating consumers and RPs about their responsibilities. To the extent the resources of this community can be channeled towards that objective, I believe FIDO can serve the world admirably for at least a few decades.

On 1/24/22 6:17 AM, Emil Lundberg wrote:

So if an RP has implemented WebAuthn without .. validating attestation statements, .. its security posture would be undermined .., then that RP has unfortunately based its implementation on incorrect assumptions. ... maybe we could somehow point all of this out more clearly to the reader.

— Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/1691#issuecomment-1020147077, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWSVTTYNIBDCDEPEDJ7BLLUXVNO3ANCNFSM5MML626A. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

MasterKale commented 2 years ago

@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 this is the phishing scenario I proposed earlier as a potential avenue for impersonating a user via cloud-synced credentials:

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.

Is this not a legitimately possible way for an attacker to abuse poor platform vendor account security (I'm not calling out Google specifically, that was just for sake of example) to then gain access to an RP (which would have been fine before with device-bound credentials) that leverages WebAuthn?

timcappalli commented 2 years ago

@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 this is the phishing scenario I proposed earlier as a potential avenue for impersonating a user via cloud-synced credentials:

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.

Is this not a legitimately possible way for an attacker to abuse poor platform vendor account security (I'm not calling out Google specifically, that was just for sake of example) to then gain access to an RP (which would have been fine before with device-bound credentials) that leverages WebAuthn?

I'd argue that this does not change the phishing resistance property of a WebAuthn credential. I think two different concerns are being conflated.

Also, you are making assumptions that only the primary account credential grants access to "synced" credentials. We know for a fact that this is not the case for the platform provider that currently has beta code available.

MasterKale commented 2 years ago

Also, you are making assumptions that only the primary account credential grants access to "synced" credentials. We know for a fact that this is not the case for the platform provider that currently has beta code available.

A single tech preview of passkeys to date by a platform vendor that historically plays things close to the chest has made it difficult to draw any strong conclusions about how other platform vendors will implement passkeys.

If Google and Microsoft follow suit with a secondary credential like iCloud Keychain passcode then I take your point that just phishing the primary account credentials would be insufficient.

I look forward to the day we can all practically see passkeys for ourselves across all major vendors to give everyone more confidence that passkeys are indeed a good direction for WebAuthn.

dwaite commented 2 years ago

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.

maxhata commented 2 years ago

RPs need to enable the flow that is shown in the following URL for all platform authenticators.

https://docs.google.com/presentation/d/14WXRLDcOOf-3cdnAEBXh2Z_bA8LtLb7FbZE4vNmuPnM/edit?usp=sharing

It is to ensure backward compatibility. How can WebAuthn spec help?

timcappalli commented 2 years ago

RPs need to enable the flow that is shown in the following URL for all platform authenticators.

https://docs.google.com/presentation/d/14WXRLDcOOf-3cdnAEBXh2Z_bA8LtLb7FbZE4vNmuPnM/edit?usp=sharing

It is to ensure backward compatibility. How can WebAuthn spec help?

@maxhata from a spec perspective, usage of the device public key extension cannot be enforced, in the same way that attestation is not required today. This is something that should be discussed in FIDO Alliance at the SPWG.

dwaite commented 2 years ago

I am not particularly concerned about the big 3 platform authenticators they will support dpk and be certified or have a large enough base that RP will hard code their attestations and make decisions to trust them or not.

The certification requirement is mostly for all the other authenticators that will implement multi-device strategies to compete in the consumer market. We are opening a can of worms here for more than just platform authenticators.

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

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

I do think we need something separate from dpk as well to indicate if a credential is multi device and if it has been backed up/ durable or whatever we are going to call it.

We should target behavior which relying parties need rather than implementation details here, similar to how we now talk about discoverable credentials rather than resident key credentials.

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.

Finally, it makes a lot more sense to have indicators for such things if the behavior is dynamic. An off-the cuff example would be a isRecoverableCredentialCreationAvailable() call in addition to new creation request options.

Firstyear commented 2 years ago

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 might be a passkey, but's it's not definitive, there is no way to make it definitive, because all a passkey implementor has to do to lie, is just omit DPK or whatever flags are decided on.

@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.

timcappalli commented 2 years ago

Look at the DPK proposal, the whole point is to just signal that something might be a passkey, but's it's not definitive, there is no way to make it definitive, because all a passkey implementor has to do to lie, is just omit DPK or whatever flags are decided on.

@Firstyear not really correct. The DPK is simply a second, hardware-bound key and can be used if the credential is a multi-device WebAuthn credential or a single-device WebAuthn credential. It does not specifically signal whether multi-device or single-device WebAuthn credentials are being used.

@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.

Access to the platform provider's cloud account does not necessarily grant access to backed up credentials. That is an assumption you are making.

Firstyear commented 2 years ago

Access to the platform provider's cloud account does not necessarily grant access to backup credentials. That is an assumption you are making.

Uh huh. Then how does passkey work then? Because if I enroll webauthn on say ... my macbook pro, and then go to my phone and use the same webauthn token, the private key must have been transmitted between the two devices. And if I enroll a new ipad to my account, it also gets the private key.

That means the access to my icloud account allows the private key to be retrieved. So the security of that private key hinges on the security of my icloud account.

timcappalli commented 2 years ago

In that specific example, your assumption is actually incorrect. But this is not the place for vendor-specific implementation discussions. This issue is about whether the DPK should be required.

Firstyear commented 2 years ago

Okay, in that case - No, it shouldn't be required, because we already have passkey devices in the world that DONT provide dpk, and RP's have to learn to cope with this situation.

timcappalli commented 2 years ago

Just clarifying, since it is important, there are currently no platforms that support multi-device WebAuthn credentials in production.

Firstyear commented 2 years ago

The author of this issue basicly wants a credProps flag for "multi-device: true".

https://www.w3.org/TR/webauthn-2/#sctn-authenticator-credential-properties-extension

Just extend credProps with that, and you have a signed extension that does what they want (with all the caveats of extensions already discussed)

And while we're at it, flags for platform/roaming would be nice.

dwaite commented 2 years ago

Just extend credProps with that, and you have a signed extension that does what they want (with all the caveats of extensions already discussed)

The credProps extension is a client extension not an authenticator extension. Client extensions are not signed (and authenticator extensions are only signed on creation if you have attestations.)

And while we're at it, flags for platform/roaming would be nice.

I believe you can accomplish this by checking getTransports() for internal. We will eventually/hopefully have authenticators which are both platform and capable of roaming (e.g. a phone used as an authenticator for other clients over a wire/network/proximity protocol in addition to having integrated platform support)

Firstyear commented 2 years ago

And while we're at it, flags for platform/roaming would be nice.

I believe you can accomplish this by checking getTransports() for internal. We will eventually/hopefully have authenticators which are both platform and capable of roaming (e.g. a phone used as an authenticator for other clients over a wire/network/proximity protocol in addition to having integrated platform support)

IIRC this is not signed and can be tampered with.

rlin1 commented 2 years ago

The right approach would be to add that to the FIDO Metadata Statement. A related issue has already been filed.

maxhata commented 2 years ago

What RPs need to know on multi-device WebAuthn credentials is: when invoking get() for authentication, if the assertion is coming back from 1) an already accepted device or 2) an new (unknown) device. RPs consider 2) may be less trusted so that they can run their own risk engine. They will determine if the assertion coming from the new device can be trusted based on their own policy. The RP can bear the full legal responsibility for the decision if any incidents to happen. Such RPs cannot accept multi-device WebAuthn credentials from unknown devices that includes unknown security characteristics of the platform vendor as well as the user's security setting of the platform vendor's account at a time, despite all the benefits and convenience that multi-device WebAuthn credentials can offer .

This is why dpk should always be provided if multi-device WebAuthn credentials are provided. They are inseparable companion features to ensure backward compatibility on the security model where the credentials were bound to devices. It is disappointing if WebAuthn cannot mandate such an important issue.

MasterKale commented 2 years ago

...when invoking get() for authentication, if the assertion is coming back from 1) an already accepted device or 2) an new (unknown) device.

Well, we are talking about a browser API...would a cookie be an unacceptable way of gauging whether the .get() call is from a new device or not?

Something like this:

When the user's browser sends the .get() response to your server you can check, was the authed-on-this-device-before cookie set?

If so, then this device can be trusted. Allow the auth to proceed.

If not, then confirm the auth is legitimate (i.e. uses a previously-registered credential belonging to a valid user account) but then force the user to provide more information to satisfy the risk engine. Upon successful auth set a long-lived, HttpOnly authed-on-this-device-before cookie.

So long as the cookie is long-lived and refreshes on subsequent auths then the user will only ever have to provide that extra info the next time they log into a new device that can successfully respond to the .get() call.

Edit: I think I lost the thread a bit, I thought we were trying to identify multi-device WebAuthn credentials before dpk is available. You can probably disregard this idea since at best it only gives you an app-level understanding of when a multi-device cred is used.

timcappalli commented 2 years ago

This is why dpk should always be provided if multi-device WebAuthn credentials are provided. They are inseparable companion features to ensure backward compatibility on the security model where the credentials were bound to devices. It is disappointing if WebAuthn cannot mandate such an important issue.

@maxhata, please be sure to take a look at the pull request for devicePubKey, specifically the scope parameter. The DPK may be more specific than just device-level on some platforms.

akshayku commented 2 years ago

@maxhata

https://docs.google.com/presentation/d/14WXRLDcOOf-3cdnAEBXh2Z_bA8LtLb7FbZE4vNmuPnM/edit?usp=sharing

This assumes that if RP is not using dpk, then it is less secure. Which is not a correct assumption. Also, as of today, authenticators don't provide dpk and we have to acknowledge and preserve the behavior for backwords compatibility. For example, there will be multiple versions of Windows for years to come which will never give you dpk and does not support sync/backup capability. My point here is if there are authenticators that does not support sync/backup capability as of now (which most of them currently are) and are code locked, there is no dpk for them. And as an RP, you can't forget about them and assume that dpk is always provided.

I think I agree with you that if someone is implementing backup/sync like multi-device passkeys, then they should provide dpk for security conscious RPs for risk analysis. But in WebAuthn, all the extensions are optional and we can't mandate an extension in WebAuthn spec. I am against changing the status quo in WebAuthn regarding extensions. Correct place to discuss this is in FIDO (TWG or SPWG).

dpk, as per current definition in the PR is that it is just another key which is device bound. It does not tell whether primary credential is device bound or not.

I think we require another signal for an RP who cares to determine whether credential created is device bound or not and whether backup/sync has happened or not for an RP to go ahead with deletion of passwords from the account. The original proposal in https://github.com/w3c/webauthn/issues/1637#issue-935187400 around this is durables flag. But I think we need either more flags or another extension because it has more states than just two to support user journeys/choices around backup.

Windows current thinking is that if and when we implement multi-device backup, user will be given a choice of whether they want these credentials to be backed-up or not at registration time. User may also have ability to choose sync/backup state in the future depending on various factors like access to sync/backup fabric etc and it's properties. Which means that backup state of the credential can change over time. And RP should be able to determine what is happening from the authenticator responses. I was thinking about extension with more detailed state, but two flags can also work as proposed by @ve7jtb. I have opened an issue for this - https://github.com/w3c/webauthn/issues/1692