duo-labs / webauthn.io

The source code for webauthn.io, a demonstration of WebAuthn.
https://webauthn.io
BSD 3-Clause "New" or "Revised" License
645 stars 120 forks source link

Webauthn.io does not show generated credential type properly #68

Closed Kieun closed 11 months ago

Kieun commented 1 year ago

Although the credential is discoverable passkey (backup enabled), the authentication success page does not properly show the credential info.

I just try to CDA with Android passkey and macOS with empty allow list and it works well except the credential information is not matched one that I created before.

Expected credential type: discoverable multi-device credential Current credential type: non-discoverable passkey

MasterKale commented 1 year ago

I think the issue here is that I rely solely on the credProps extension to determine if a credential is discoverable or not when it's created. I don't think Android supports it yet, so because I don't get anything back that flag ends up getting set to false when I save the credential.

I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.

Kieun commented 1 year ago

The way of our Webauthn server implementation determines whether the credential is discoverable or not is as follows.

  1. Check resident key option first a. If the resident key option is required, then successfully registered credential is discoverable credential b. If the resident key option is either preferred or discouraged, then we cannot determine the credential type
  2. If the credProps supported a. rk is returned as true, the credential is discoverable b. rk is returned as false, the credential is non-discoverable
  3. If the credential type is not determined, then set it as unknown

So, our server implementation's credential type regarding the discoverability has tri-value (discoverable, non-discoverable, unknown). This is reasonable and safe way of determining of discoverability of the credential.

I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.

I'm not sure this is safe assumption. Maybe, later, non-discoverable credential (such as U2F, FIDO2 roaming authenticator) might provide backup feature. In this case, the backup targets for those authenticators are the wrapping key. So, the wrapping key moves around (import/export and even backup) across devices.

vincentdelitz commented 11 months ago

I think the issue here is that I rely solely on the credProps extension to determine if a credential is discoverable or not when it's created. I don't think Android supports it yet, so because I don't get anything back that flag ends up getting set to false when I save the credential.

I suppose it's safe enough to assume a backup-eligible credential is a discoverable credential. I'll take a look next week and confirm.

Is there any update on this one yet (or in general on more devices e.g. iOS or macOS), where the demo also states "Non-discoverable credential" due to the empty credProps extension)?

MasterKale commented 11 months ago

@Kieun @vincentdelitz I just updated webauthn.io with some updated credential labeling:

Screenshot 2023-09-28 at 3 52 05 PM

Top: iCloud Keychain passkey, 1Password extension passkey Bottom: macOS Chrome passkey, U2F security key

I'm going to consider this issue finally closed. Let me know what you think, and open a new issue if you think it needs tweaks.

vincentdelitz commented 11 months ago

Thanks @MasterKale. I think that's now a good description that helps to better understand the different type of keys. Based on your updated implementation and the scheme provided by @Kieun above, we did a quick test here on some authenticators to check the behavior.

Great help is also this article, that our test above is built on (extends the table basically).