devicePubKey extension MUST be supported if multi-device WebAuthn credentials are used #1691
Comments
|
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. |
|
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? |
|
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). |
|
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". |
|
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.
How will this be avoided? How can the WebAuthN spec help solve? |
|
@maxhata I'm not following this statement:
An RP can still continue using security keys (single-device passkeys) as well as platform authenticators that support single-device passkeys. |
|
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. |
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. |
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?" |
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 😛 |
|
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 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. 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. That could also all be a separate extension if we want to give RP the option of asking for it or not. 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. |
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. |
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 |
|
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. |
|
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, 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 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. |
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. |
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. |
|
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. |
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
https://www.w3.org/TR/webauthn-2/#public-key-credential-source
https://www.w3.org/TR/webauthn-2/#bound-credential
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:
An RP assuming device-bound credentials has no defense against this without the 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. |
|
The spec states as such in several places (emphases mine):
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. |
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?
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. |
|
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
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? |
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.
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:
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. |
|
I agree that authenticators that support multi device web authn credentials should support dpk. 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. |
@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. |
|
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. |
|
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):
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. |
|
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
<#1691 (comment)>,
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:
***@***.***>
|
@timcappalli this is the phishing scenario I proposed earlier as a potential avenue for impersonating a user via cloud-synced credentials:
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? |
@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. |
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.
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 |
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.
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 ...
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.
@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. |
@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.
Access to the platform provider's cloud account does not necessarily grant access to backed up 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. |
|
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. |
|
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. |
|
Just clarifying, since it is important, there are currently no platforms that support multi-device WebAuthn credentials in production. |
|
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. |
timcappalli
changed the title
The
I believe you can accomplish this by checking getTransports() for |
IIRC this is not signed and can be tampered with. |
|
The right approach would be to add that to the FIDO Metadata Statement. A related issue has already been filed. |
|
What RPs need to know on multi-device WebAuthn credentials is: This is why dpk should always be provided if multi-device WebAuthn credentials are provided. |
Well, we are talking about a browser API...would a cookie be an unacceptable way of gauging whether the Something like this:
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 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. |
@maxhata, please be sure to take a look at the pull request for devicePubKey, specifically the |
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 #1637 (comment) around this is 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 - #1692 |
|
Seriously, folks?? It would seem to me, that when dozens to hundreds of FIDO manufacturers have invested years into implementing FIDO solutions with certain security notions, as a courtesy to all that effort and investments - and to instill the principle of "secure by default" - the DEFAULT for a FIDO credential should ALWAYS be a hardware-bound key-pair, with NO possibility of ever extracting, copying, cloning, moving, synchronizing or backing up that key-pair to anything, anywhere. If new entrants to the market desire convenience and are willing to sacrifice security for that illusory benefit, then those people/companies should bear the burden of new extension request and response processing, and dealing with the ensuing complexity. Why should the people/companies who have invested more than 7 years into building "secure by default" FIDO solutions have to perform ANY additional work just to maintain what they always believed the FIDO value-proposition would be? |
|
@arshadnoor nothing is changing for the authenticators that you are describing. The DPK is not designed for or needed with a single-device WebAuthn credential (e.g. credentials on a security key). |
|
Is that a guarantee, @timcappalli? Does that include platform key-pairs too? Will the FIDO Alliance make "synchronized key-pairs/credentials" mandatory or optional for server manufacturers to get certified? Will all those people who have invested in web/mobile applications never have to change their web/mobile apps when Level-3 is standardized if they do not wish to support synchronized key-pairs/credentials? |
|
@arshadnoor The core problem is that passwords are portable while platform authenticators are not, making the dream eliminating passwords unrealistic. Obviously there will be RPs that won't bother with multi-device passkeys. If this feature becomes a part of the attestation all will be good although it will require minor RP software updates. A FIDO ecosystem that only supports a handful of RPs may not even be sustainable. A major problem with the original FIDO concept is that the market known as "retail" (consumer) banking is now faced with a FIDO powered payment authorization standard that greatly underperforms compared to the banks' own proprietary "app" solutions, not to mention Apple Pay. If you take a look at "settings" in Chrome and Edge you will find payment methods. That is, payment instrument metadata is already there but the WebAuthn folks came to the conclusion that it is better that users keep their current plastic cards at hand when paying rather than connecting the dots (Trusted UI + Strong authentication + Payment instrument meta data = Wallet). The rationale for this decision (which has considerable Privacy, UX, and Deployment downsides), has never been discussed in open so I guess there must be an underlying commercial issue. However, it gets worse; the in Europe quite popular "PayWithYourBank" schemes require yet another and quite awkward standard-to-be, while (re)using the already existing meta data would (almost) work right out of the box! |
|
@arshadnoor Noone is trying to force synced keys on anyone, but the reality is that they have always been possible, and are likely to become more common as WebAuthn adoption increases. When WebAuthn L1 was published in March 2019, nothing was stopping you from building a browser with a software authenticator with cloud sync, or an Arduino USB device that speaks CTAP1 and lets you import and export key material. If an RP wanted to forbid such authenticators, it had to require authenticator attestation and enforce an attestation allow-list. This was true then and it will be true tomorrow - RPs may do extra work to place restrictions, but if they don't, users are free to choose an authenticator with the features they want. This goes the other way too: the user is also free to choose a hardware authenticator from which key material cannot be extracted, and nothing will change for existing or future authenticators that choose this path. This working group cannot speak for what the FIDO Alliance will decide for their certifications.
If they are already enforcing an attestation allow-list, then indeed nothing will change. If they are not, then as noted above, they have based their implementation on assumptions that have always been incorrect. RPs don't need to do anything to support synced keys, but the effort required to not support them is not new. @cyberphone Please stay on the issue topic, web payments are unrelated to this. |
This extension is meant to give RPs an additional signal to let them accept authenticators that their policy would otherwise deny. It is meant to allow RPs a means to implement more expressive policies. If an RP policy is to always reject authenticators based on their key-storage properties there's no reason to use this extension at all. To implement that policy today they do need attestations, and they will continue to need them in the future. If instead the policy is extended to accept certain authenticators but to invoke user-facing workflow when the authentication may be coming from new hardware, the onus of providing support for that new workflow would fall onto the user-facing portion of the RP (a web application I believe in your example). |
You are completely right! There is no way for an RP to detect a synchronised key today or in the future, regardless of DPK existing or not. :) |
|
Hi @emlun
They are related because Web payment systems that do not intrinsically host required meta data, usually depend on cookies to achieve a more reasonable UX (like remembering last used card number). Payment systems relying on WebAuthn belong to this category. That is, synced keys may also need synced cookies. SPC raises the bar further by adding dependencies on synced payment handler code. Hopefully all of this is taking place at the platform level, otherwise you are stuck with the default browser which yet another thorny topic. For Apple who only supports a single "engine" this is a no-issue, for the rest of the world, it is not. IMO, this is way over the top, particularly with respect to payments. For user authentication, discoverable authenticators are probably sufficient to relieve us from the current "cookie hell". |
|
Accompanying @akshayku's outline of Windows' thinking (above), chrome's position on RP's discriminating amongst authenticators, passkey emergence, etc, is summarized in this post by @agl on issue #1688 As noted in Explainer: broadening the user base of WebAuthn, the overall goal with passkeys and the accompanying various features, the overall goal is "...to make WebAuthn more broadly applicable as a password replacement." |
|
As discussed on the working group call and in this thread, the enforcement of extensions for purposes defined outside of the spec (in this case, for passkeys) falls outside of the responsibility of the working group, and would better be suited for enforcement by a certification group. |
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.
The text was updated successfully, but these errors were encountered: