Passkey Limitations and Adoption Considerations

Apple announced Passkey in WWDC’22 a year ago. Both Microsoft and Google quickly followed suit, announcing their support in the RSA and IdentiVerse conferences. Passkey is promising to potentially replace passwords eventually, but the road to that promise may be long and bumpy. There are at least 3 issues that will prevent a widespread adoption in the short term, which I will elaborate in this post. If you want to adopt Passkey in your app, read on to understand the implications and think through how to overcome those limitations.

Background

Before I describe its limitations, let us understand what is Passkey first. Passkey builds on FIDO2 set of specifications. FIDO2 specifies a new way to register and sign in to an app or a website, which is also referred to as a RP (Relying Party) in the spec. When a user registers with a RP, a private/public key pair is generated (e.g., by a browser). The private key is stored on the client and it is kept private, and the public key is stored at the RP. When the user subsequently logs in, the RP sends a unique nonce for the client to sign with its private key. When the RP is able to verify that the nonce is signed with the private key corresponding to its public key, the RP is certain that the client is the same user as the one during the registration. This process is illustrated in the figure below.

In the current FIDO2 implementation, the private key is typically stored on a hardware module, such as a TPM (Trusted Platform Module), on the user’s device. The private key can be used to sign a nonce, but it can never be exported, so it is secure.

Passkey extends FIDO2 in two ways.

1. Passkey allows the private key to be synced across devices, e.g., through the iCloud keychain. This is actually not part of the FIDO2 spec. FIDO2 does not prescribe how the key should be stored on the client side, however, Passkey makes it explicit that the key may be synced outside of a device. Passkey is a vendor implementation term, and in the FIDO community, it is officially called multi-device credential.
2. Passkey introduces a new protocol to allow a phone to be used as a roaming authenticator. This is the demo Apple showed in WWDC, where the website pops up a QR code, and users use their phones to scan and authenticate. The private key is stored on the phone, and a communication protocol allows the signed nonce to be transmitted from the phone to the app to authenticate the user.

There are a lot of advantages of FIDO2, which are highlighted in the Apple presentation, including:

• No shared secret. like password, so nothing to steal from the server side.
• Not phishable. Phishing is the #1 vulnerability today. The FIDO2 protocol makes sure that it only signs a nonce corresponding to the right RP. No more tricking people into believing when you visit a fake website.

Because of these inherent advantages, Passkey will eventually replace password, but there are several challenges along the way.

Challenge 1: Lower security level

The first challenge for adoption is that Passkey lowers the security promise. Before Passkey, the FIDO2 private key was typically stored on a hardware TPM module if available, which has the nice property that guarantees the key could not be exported. To understand the impact, it is helpful to understand how NIST (National Institute of Standards and Technology) thinks about security levels. NIST defines three Authenticator Assurance Level (AAL):

• AAL1: You just need to prove you control one authenticator that is bound to the account. The single authenticator could just be a password.
• AAL2: Proof of possession and control of two distinct authentication factors are required. This is also often referred to as the Multi-Factor Authentication (MFA). An example is SMS verification in addition to password.
• AAL3: It is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). A key requirement of AAL3 is that the private key cannot be exported, so that, by proving that you own the private key, you also prove that you possess the hardware device.

The figure above (courtesy of Shane’s RSA presentation) illustrates the security tradeoffs between various sign in methods, from the least secure to the left, to the most secure on the right. Prior to Passkey, the default is “Device-bound FIDO credential” when FIDO authentication is used, which is the most secure. By introducing Passkey, we move to “multi-device passkey”.

The use of Passkey is a platform decision. There is not an option for either the RP or the user to disable Passkey, i.e., it is not possible to choose “device-bound FIDO credential” anymore.

FIDO alliance is working on a new device-bound-key extension, which allows an RP to request an additional key that is both unique and bounded to the device. If a device-bound-key exists, RP can verify if the device is a known device. Or, if a device-bound-key does not exist, RP will know the authentication is happening in a new device, and it can step up authentication if needed. Device-bound-key provides AAL3 security assurance, but unfortunately, it is an optional extension that may not get widespread adoption by vendors.

Challenge 2: Sync across ecosystems

Passkey relies on client side synchronization to distribute the keys to users’ devices. The synchronization mechanism is vendor specific. There are three potential layers at which the keys could be synchronized.

1. Platform level: This is a capability provided by the OS vendor that is built-in to the OS. An example is the iCloud keychain. The OS vendors manage the users’ identity and their devices, and they propagate the private key across devices the users own.
2. Browser level: Browsers also provide an ability for users to login an account, and synchronize their data. For example, in Chrome, you can login to your Google account, and sync data across all browser instances, potentially on multiple devices across OS ecosystems (e.g., between iOS, Windows, Mac and Android).
3. App level: A password manager app is used widely to synchronize passwords at the application level, and a similar or same app could do the same thing for passkeys. They may have to use a browser plugin to hook into the sign-in/registration process. To synchronize passkeys, a passkey manager app needs an interface to interact with the authenticators to access the keys.

The current passkey implementation will sync keys at the platform level, although there might be an option to expose an OS interface to allow app level syncing in the future.

The current direction of platform level key syncing presents challenges.

1. First, the platform may not have visibility to all keys in all browsers. MacOS behaves differently than other platforms, such as iOS, Android and Windows. On MacOS, different browsers see a different subset of the platform authenticator, e.g., the TouchID authenticator. When chrome creates a FIDO key, the key is not visible to other browsers, such as Safai and Firefox, or vice versa. Apple platform will only sync keys created by Safari, and because of the key isolation, keys created by other browsers such as Chrome and Safari will not be synced beyond the MacOS device.

1. This behavior will be confusing to an end user. Users may create a FIDO2 key in Chrome on MacOS, and assume that the key will be sync’ed by iCloud keychain, as implied by Apple’s passkey annoucement. But, in reality, they will be suprised when the keys are not available on their iOS devices.
2. While there is a plan to change this behavior, it will likely take some time, since it requires both OS and browsers to change.
3. Second, cross platform experience is confusing to the end users. There are several scenarios:

• If you are largely in the Apple ecosystem, the experience is ok (except the multi-browser scenario on MacOS as described above). The keys in your iPhone, iPad and Mac all sync through iCloud Keychain. The only challenge is when you decide to switch platform (e.g., to Windows). There is no mechanism to export keys in bulk, so your keys are stuck in the iCloud.
• If you use Windows, your experience is much worse. Because Microsoft does not own a mobile platform, your keys are likely spread over multiple platforms, e.g, Windows and Android. The keys you register on your Windows machine are isolated from the keys you register on Android or iOS when you are on the mobile platforms. You have to constantly remember where your keys are stored on what platform when you login to a RP. One possible solution is to make sure all your keys are stored on your mobile platform. Since mobile platforms support QR code scanning, they not only can be used to log you into an RP from your phone, but they can also log you into an RP on Windows. Unfortunately, the QR scanning experience is cumbersome, which involves extra clicks to bring up the QR code, and hunting for the mobile phone to scan and complete the login.

Microsoft and Google could have built a much better user experience had they chosen to sync the keys at the browser level. Neither of them own both the desktop and mobile platforms, so their users would have to live with the cross-platform clunkiness if they own both desktop and mobile devices.

Challenge 3: Explicitly manage multiple private/public keys

With passwords, there is only 1 shared secret to store on the server side. Disabling login is as simple as removing the shared secret on the server. With passkeys, there are multiple private/public key pairs, with at least one pair for each platform. Disabling login requires the user to understand which key is used on each platform, and to make sure deleting the correct key. Removing the wrong public key would mean the user can no longer login on the corresponding platform.

The user also must be conscious that there are a pair of keys for each credential. Removing the public key on the RP is sufficient to revoke access, but the private key may still be visible on the client side, which may be confusing to the user.

The transition to passkey is happening. Apple’s implementation will be out shortly, Android’s and Windows’ implementation will quickly follow. If you support WebAuthn/FIDO2 on your RP already, or if you plan to adopt passkey-based login directly, consider these recommendations.

Adoption considerations

1. Add recovery options. While Apple makes it sounds like passkey is all you need in their announcements, there are many scenarios where you cannot rely on passkey being there. Not only that users may switch platform, but even if a user stays in the Apple ecosystem, they may be using Chrome on their Mac, which would require a separate set of keys from their iCloud passkeys. To make sure a user can still login, you should add other options to allow a user to login, possibly as a recovery mechanism. Potential mechanisms can be Magic Link, or OTP code over SMS, or security questions. When a user uses a recovery mechanism to login on a new platform/device/browser, you can then generate new keypairs to allow users to login with passkeys on the same device in the future.
2. Detect and enhance security assurance as needed. If your app requires AAL3 level assurance, you can no longer assume the FIDO2 keys are device bound. You have to introduce additional logic to ensure high assurance level, which could be as follows:

• First, you should detect if Passkey is used. WebAuthn (the Javascript API for FIDO2) enhanced the protocol to offer two additional bits of information: credential backup eligibility (BE) and current backup state (BS) in the authenticator data. BE is set to true when Passkey is used.
• Second, detect if device-bound-key extension is supported. device-bound-key is an optional enhancement to FIDO2. It is still under definition, and not all browsers will implement it. But if the browser supports it, you can request device-bound-key to ensure AAL3 security level.
• Third, if device-bound-key extension is not available, you have to implement your own device detection, and step up authentication if a new devie is found. For example, you can use a browser cookie to remember if the user has logged in from the browser before, and add step up authentication logic if a new device is used.

3. Record User Agent. The user could have multiple keys from multiple platforms/browsers, and it becomes confusing to the end user on how to manage the keys. Remembering the user agent during enrollment could help the user distinguish between the different keys. Optionally, during enrollment, you could also ask the user for a unique name to identify the key, and store the unique name along with the key. Additional user education may also be required as they transition from paswords to passkeys.

Conclusion

We are at the early stage of passkey adoption, a lot of user experience quarks need to be worked out, and more user education is needed. The blog highlights some challenges that we need to consider, hopefully it helps you think through solutions to help your users transition successfully.

Note: this blog is also posted in my wordpress blog site.