iCloud wipes existing passkey on registration

[James Hartig]

Hello,

We've had multiple users now lose access to their account because iCloud only supports a single passkey per domain and blindly overwrites it during registration. If a user registers for an RP with a passkey (passkey 1) then the RP and iCloud both have passkey 1. But then if the user tries to add a second passkey to their RP which initiates the registration flow and happens to choose iCloud Keychain then a new passkey is created (passkey 2) and passkey 1 is immediately replaced in the iCloud Keychain. Now the RP has passkey 1 and their iCloud Keychain has passkey 2. If the user does not complete the passkey process then they've now lost access to their account.

Another wrinkle is that we require users to authenticate their account as part of adding a new passkey. Once users have started the registration flow and iCloud has replaced their old passkey they cannot authenticate with that "old" passkey anymore so they aren't able to even complete the flow for adding a new passkey.

How are other RPs dealing with this? We do send excludeCredentials as part of the registration flow with the descriptions of their existing credentials but Mac seems to ignore that.

Thanks!

[Fatih Deli]

28 Mar 2024 Per, saat 00:35 tarihinde 'James Hartig' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> şunu yazdı:

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4417d295-eb4b-4eaa-9a51-d736a9b78ed2n%40fidoalliance.org.

[Fatih Deli]

Tamam 

28 Mar 2024 Per, saat 00:37 tarihinde Fatih Deli <fatihd...@gmail.com> şunu yazdı:

[Tim Cappalli]

because iCloud only supports a single passkey per domain and blindly overwrites it during registration

Just as an informational point, it is not one passkey per domain. It is one passkey per user handle (e.g. account) per RP ID (domain).

RE: excludeCredentials, there is an open bug for this: https://bugs.webkit.org/show_bug.cgi?id=270553

On Wed, Mar 27, 2024 at 5:35 PM 'James Hartig' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:

This message originated outside your organization.

---

[Shane Weeden]

Couple of comments:

>  If the user does not complete the passkey process then they've now lost access to their account.

Try to minimise the likelihood of that happening by having the submission of the results of the navigator.credentials.create call to the RP be something that happens immediately following the ceremony. That is, don’t problem for a friendly name first, or have other interactive UX - just register it against the account straight away.

> Another wrinkle is that we require users to authenticate their account as part of adding a new passkey.

If you do that authentication *prior to* the call to navigator.credentials.create for new passkey registration, rather than after, then this wouldn’t be a problem.

I’m neither condoning nor criticising Safari / MacOS behaviour, but simply trying to offer a pattern that might mitigate the problem you are reporting.

Cheers,

Shane.

[Daniel Shumway]

> If the user does not complete the passkey process then they've now lost access to their account.

Is the root of this problem that `navigator.credentials.create` also saves the passkey on the device at the same time as it's generated regardless of whether it's submitted or not? In other words, is there any intermediary step between the passkey getting created and saved where the system would wait for a callback or event that the RP could throw on successful registration?

Most of the docs I've read on passkey implementation always submit the PublicKeyCredential after calling `create` without adding additional error handling, but it's possible they were glossing over an optional step that I'm not aware of. I don't know, an optional `PublicKeyCredential.persist` method or something like that?

I suppose with multiple passkeys allowed per-account per-domain that might not be as much of a  problem since as long as it's not replacing an existing passkey; the new passkey could be deleted without any ill effects if the RP encountered an error saving it. Similarly, if there was a gap between `navigator.credentials.create` and saving the new passkey where the server could send a success/error response, it might not matter that the new passkey is replacing the old one.

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4417d295-eb4b-4eaa-9a51-d736a9b78ed2n%40fidoalliance.org.

Best wishes,

Daniel Shumway

[James Hartig]

> Just as an informational point, it is not one passkey per domain. It is one passkey per user handle (e.g. account) per RP ID (domain).

Good point. I didn't test the distinction and I appreciate the clarification.

>  RE: excludeCredentials, there is an open bug for this: https://bugs.webkit.org/show_bug.cgi?id=270553

Thank you for this link, I'll keep tabs on it.

> If you do that authentication *prior to* the call to navigator.credentials.create for new passkey registration, rather than after, then this wouldn’t be a problem.

Yes, we will be reworking that flow to minimize the chances it not completing. We hadn't realized this was an issue until recently so the flow was created without that risk in mind.

> Is the root of this problem that `navigator.credentials.create` also saves the passkey on the device at the same time as it's generated regardless of whether it's submitted or not? In other words, is there any intermediary step between the passkey getting created and saved where the system would wait for a callback or event that the RP could throw on successful registration?

I'm not sure how that would work in practice since the user's device would need to save the passkey but in some sort of temporary(?) state and then move it to a permanent state once persist is called but there's a chance the user removed the USB key or something else happens which leaves it stuck in the wrong state. I'd welcome this sort of change though if it could be figured out.

> I suppose with multiple passkeys allowed per-account per-domain that might not be as much of a  problem since as long as it's not replacing an existing passkey; the new passkey could be deleted without any ill effects if the RP encountered an error saving it.

Even if the existing passkey is deleted, we've at least 2 users create multiple passkeys on accident in their Google account and then be confused later which one is the right one. It's not obvious (besides trial and error) and even harder to identify the extraneous ones to delete once you've found the one that worked.

Thank you for all the quick and helpful replies!

[Tim Cappalli]

The excludeCredentials list is marked as resolved for Safari 191 (currently in technical preview). 

Just did a quick test and it does indeed appear to be fixed.