How passkeys work: Let's start the passkey registration process

6 hours ago 3

Previously on our passkey journey, I talked about the challenge of figuring out if a relying party -- typically, the operator of a website or app -- even offers the ability to sign in with a passkey instead of the more traditional and less secure username and password-based approach.

Some of the biggest relying parties in the world -- including Apple, Google, and Microsoft -- support passkeys as a means of passwordless authentication. Together, these tech giants can introduce billions of global users to the phishing and smishing-resistant technology. However, the vast majority of websites and apps have yet to follow suit. When will passkeys catch on enough that most relying parties support them and, more importantly, most users embrace them -- instead of usernames and passwords -- as their primary means of authentication? I estimate it will take another five to 10 years.

For users who want to get an idea of what it's like to work with passkeys today, one relying party that offers a basic passkey experience that you can try out is Shopfiy.com. If you have goods or services to sell, Shopify is an e-commerce service provider that makes it quick and easy to set up an online storefront and start booking sales. But you don't need to set up an online store in order to experiment with Shopify's passkey support, and so I used Shopify's website as an example of the path you might take to start a passkey enrollment process.

Although the path is a typical one, there'll be differences in the passkey user experience from one relying party to the next. Those inconsistencies -- minor though they may be -- are likely to confuse users accustomed to the nearly universal workflow for username and password-based authentication.

In the previous installment[, we found our way to Shopify's "Create a Passkey" button (shown below), and I described what happened next as a bit of a technological ordeal.

Up until now, the process has been relatively straightforward -- just navigating some menus to find our way to Shopify.com's security settings. But, regardless of the relying party, that ordeal starts once you click the "Create a passkey" button (or equivalent) to start the passkey enrollment ceremony. Whether or not you successfully enroll a passkey depends on a variety of factors, including your browser, your operating system, and your choice of authenticator.

(Of the six parts in this ZDNET series, I'm dividing my coverage of the passkey registration ceremony into two parts: This part is about choosing an authenticator -- required for all passkeys. The next part describes what happens behind the scenes once you've chosen an authenticator.)

Authenticator vs password manager

Before we continue our passkey journey, it's important to distinguish between an authenticator and a password manager.

In the passkey world, an authenticator is the technology that not only creates and stores the public and private key components of a passkey, but that also retrieves passkeys during any authentication ceremonies. This could be a password manager -- like Google's Password Manager that's built into your web browser, or a third-party BYO password manager like Bitwarden, Dashlane, or NordPass. Alternatively, an authenticator could involve a combination of your device's operating system and any local security hardware, such as a trusted platform module (TPM), a secure enclave, or a third-party FIDO2-compliant roaming authenticator such as one of Yubico's Yubikeys (which, in itself, is not a password manager).

Importantly, whereas most of today's password managers are FIDO2-compliant authenticators, not all authenticators (e.g., the Yubikey) are password managers. Also, bear in mind that the word "authenticator" means different things to different technology vendors and their customers. Whereas Google Authenticator is for generating timed one-time passwords (TOTPs) as a form of multi-factor authentication and currently has nothing to do with passkeys, Microsoft Authenticator is a password manager, a TOTP generator, and a limited passkey authenticator all wrapped into one product. However, in a signal to the industry that it wants to rid the world of passwords in favor of passkeys, Microsoft is about to ditch its authenticator's support for passwords. The industry has -- quite needlessly -- made the word "authenticator" confusing.

The FIDO Alliance is a consortium of organizations -- including Apple, Google, and Microsoft -- that maintains and promotes authentication standards to reduce reliance on passwords. In 2021, in the course of revealing its implementation of FIDO2-compliant credentials, Apple referred to them as "passkeys," and the name has stuck ever since.

Also: What really happens during a passwordless login?

The wide range of authenticator choices and types speaks to some of the important decisions that every user and organization must make as they plan their passkey journey. My Top 10 Passkey Survival Tips covers some ideas for that planning.

In terms of your bigger-picture passkey strategy, note that you can use different authenticators for different passkeys. For example, whereas I use Bitwarden as my authenticator for most of the websites I visit, I configured a YubiKey as an authenticator for my Bitwarden account. Additionally, most relying parties allow you to create multiple passkeys for the same account. In my case, I've configured two passkeys for my Gmail account, and each relies on a different roaming authenticator.

Initiating the passkey enrollment ceremony

OK, on with our journey.

Once a relying party's button to create a passkey is clicked, the passkey registration ceremony begins. The end-to-end process involves some very visible user interface elements as well as some very technical stuff that happens behind the scenes. I'll cover both.

When the relying party's server receives the indication that you want to initiate a passkey registration ceremony, the server transparently responds to your web browser with a time-sensitive offer (officially called the PublicKeyCredentialCreationOptions) of WebAuthn credential configuration options for both your browser and any authenticators to follow. Remember (from Part 1 of this series), the credential is ultimately a passkey, but a passkey itself is a type of WebAuthn credential.

Within this offer are certain parameters whose role is to securely create your passkey for one relying party and one relying party only. Once created, it cannot be used to log in to an impostor website the way your password can. So, unlike passwords -- secrets that are relatively insecure from the moment you first create and share them with a relying party (and then for the rest of their lives) -- passkeys are secure from birth, partially due to these credential creation options.

In addition to including a machine-generated non-human-readable user ID (from this point forward, referred to as the user.id) which is unique to the user (and usable in subsequent authentication ceremonies), one of the other inclusions in the PublicKeyCredentialCreationOptions is the rpId -- essentially, the identity of the relying party. The content (an internet domain or subdomain) of this field must match the origin domain (e.g. "shopify.com") that your device's browser sees as the origin domain of the aforementioned server response. (It uses the same integrity-checking mechanisms that your browser uses to double-check the source of any traffic it receives.) If this field is omitted, the rpId defaults to the origin domain that was observed by the browser.

The inclusion of the rpId at this moment in the registration ceremony is significant for two reasons. First, the registration should fail if the rpId doesn't match the origin domain. It essentially means "possibility of foul play." Therefore, a malicious domain cannot trick an end user into somehow registering a passkey that's advertised to work for one domain, while it actually works for another (or vice versa). However, the necessity of this test (and any red flags that result) is not nearly as important as another test that comes later during subsequent attempts to log in (aka the authentication ceremonies).

During the registration ceremony, when the relying party successfully reports its rpId to the authenticator (in other words, the rpId matches the origin domain as just described), the authenticator scopes the new passkey for only that rpId. In other words, it can only work as a passkey on the domain for which it was created. With passwords, users can be tricked into providing their login credentials to a malicious site or app. Not with passkeys. That's because, as described in Part 5 of this series, your authenticator won't even bother trying to use a passkey intended for one origin domain in order to authenticate with another.

Another important security element in the list of the PublicKeyCredentialCreationOptions is a randomly generated string of characters called the "challenge." This string is specific to the current session -- the one to register a passkey -- between your device's web browser and the relying party's server, and provides assurances that that session doesn't get intercepted and replayed at a later time by a malicious actor.

In addition to these security precautions, the PublicKeyCredentialCreationOptions enable the relying party to allow certain authenticator types and disallow others while also specifying how much time in milliseconds the user has to respond to the offer before it expires. For example, a timeout setting of 30,000 milliseconds allows the user 30 seconds before the offer to register a passkey with the included challenge is essentially withdrawn.

The relying party can also (optionally) require the user to provide a fingerprint, facial ID, or PIN whenever they attempt to login with the newly created passkey. But, based on my experiences, some relying parties do not exercise this option. And even if they did, authenticators are not obligated to respect it.

Also: To change or delete a passkey, you're on your own

Either way, this is one of those forks in the passkey road where important parts of the user experience are left to relying parties -- and not all relying parties are going to make the same choices.

For the foreseeable future, the resulting inconsistencies in passkey registration ceremonies (and the overall passkey user experience) will serve as a source of confusion for end users and an inhibitor of passkey adoption.

At this moment in the workflow, when you've indicated that you want to create a passkey, the relying party will ask you to re-authenticate (see screenshot below) as an extra precaution against a malicious actor trying to create one for your account. However, the user experience regarding this step varies from relying party to relying party. Some relying parties don't require re-authentication; others require your password to authenticate, even though you may have previously enrolled a passkey. (Why can't that passkey be used?)

In Shopify's case, if you've already enrolled a passkey, you're given a choice to re-authenticate with that passkey or your password. The screenshot below shows only the password option because there is no previously enrolled passkey.

After re-authenticating, you're told that the browser or device will prompt you to create the passkey once you hit the continue button, as shown below. Not all relying parties include this heads-up as part of the passkey enrollment ceremony.

Passkeys are based largely on public key cryptography, where each passkey involves a public and a private key. The latter is a secret never shared with a relying party in the same way that passwords are. The biggest security benefits of passkeys, including their phishing and smishing resistance, are anchored to this single most important aspect: The secret always stays with you, the user.

Once the web browser receives its instructions to create a passkey from the relying party, it has to figure out which authenticator to use to create it. To do this, the browser must first determine which authenticators are available at that moment. Similar to the way users can optionally configure their operating systems to respond to all web requests through a default web browser, users should be able to indicate their choice for a default authenticator to handle all authentication requests -- with an option to override that choice when the user deems it necessary. Unfortunately, users don't have the option of assigning a default authenticator, and the resulting inconsistency in passkey user experiences is one of the major shortcomings of the passkey ecosystem.

Authentication options abound

For example, the partial screenshot below shows how, in one scenario, I've installed the Chrome extension for Bitwarden's password manager to handle my authentications (red arrow) while disabling Google Password Manager through Chrome's settings (green arrow).

Theoretically, when I click Shopify's "Create a passkey button," it should assume that Bitwarden is my preferred authenticator based on the presence of the Bitwarden extension. After all, the extension is installed. However, in order for Chrome to detect the presence of Bitwarden's extension (or that of any other authenticator), the extension must first register its availability as an authenticator with Chrome -- something that it can do only once it is in an active state. As can be seen from the Bitwarden icon's gray color, Bitwarden is currently inactive (I haven't logged into it). Therefore, it is not at the moment registered with Chrome as an available authenticator. At this point, Chrome checks with the operating system to see what authenticators it knows about, and since it's a Mac running MacOS, the operating system responds by first offering the highly misleading dialog below.

Despite what the dialog says, you don't need to enable iCloud Keychain to save your passkey. You only need it when iCloud Keychain (aka Apple Passwords) is your preferred authenticator for creating and saving this and/or other passkeys. Even though it makes no sense and is likely a source of huge confusion (especially for Mac users), the complete list of available authenticator options is actually hiding behind the Cancel button.

After clicking the Cancel button, control is returned to Chrome, which in turn presents the options shown in the dialog below, one of which is iCloud Keychain. In other words, the previous dialog was not only confusing but also unnecessary.

Although a detailed exploration of all the options listed above is outside the scope of this article (the main point at this step is to pick from one of the available authenticator options), it's worth mentioning that, when you see "security key" as an authenticator option, it's referring to a roaming authenticator. Examples include Yubico's Yubikey 5 NFC and Google's Titan security keys.

Also: 10 passkey survival tips: Prepare for your passwordless future now

It's also important to note that the Chrome profile option is scheduled for deprecation. A Google spokesperson told ZDNET, "This is only a temporary solution that we plan to phase out, but it was initially helpful in a world before passkeys. To make the passkey experience more seamless, we've been investing in syncing to ensure they are available across devices and platforms. That is now the standard user experience."

That investment has been in Google Password Manager as a "platform" authenticator, which, in my second scenario, appears as an available option based on the series of screenshots below. In the first of these screenshots, Bitwarden is still inactive. But, within Chrome's settings, Google's Password Manager is toggled on as shown by the green arrow.

Even though Google Password Manager is toggled on, when it comes time to create a passkey, MacOS still insists on first presenting iCloud Keychain as the only available option, as was previously shown above. However, this time, when the Cancel button is clicked, Google Password Manager is now listed as an available option, as shown by the green arrow in the partial screenshot below.

In this third and last scenario, Google Password Manager is toggled off. However, the icon for Bitwarden's extension is now illuminated in blue and white because I activated it by logging in with my Bitwarden password. In other words, Google Password Manager is no longer available as a platform authenticator, but Bitwarden has now registered itself with Chrome as an available third-party authenticator, which in turn triggers an entirely different user experience. The World Wide Web Consortium's (W3C) WebAuthn standard officially refers to such third-party authenticators as virtual authenticators.

This time, after clicking the "Create a passkey" button on the relying party's website, both the iCloud Keychain dialog and the browser's dialog showing the list of available authenticators are bypassed, and the Bitwarden browser extension springs to life as shown in the screenshot below.

As seen above, the Bitwarden extension is active but locked. Note that BitWarden's locked state is very different from its inactive state. When it is locked, the extension is active but still requires the user to unlock it with a password, PIN, or fingerprint.

Once Bitwarden is unlocked, the enrollment ceremony will continue. However, if your passkey strategy involves multiple authenticators and you prefer to use an authenticator other than the default, you must first close the authenticator's pop-up window. At that point, the workflow automatically starts over. However, if the user makes it to the browser's list of available authenticators, virtual authenticators like Bitwarden's extension -- oddly, sadly, and inconsistently -- isn't one of them.

Note that when using a third-party extension like Bitwarden as your virtual authenticator, you should probably avoid the scenario shown in the screenshot above where both the authenticator's extension and Google Password Manager (or the equivalent platform authenticator in other browsers) are activated at the same time. When this is the case, the user will very likely encounter competing, confusing, and sometimes overlapping autofill dialogs because now, the browser is essentially getting conflicting signals about your authenticator choices.

In the next installment, we go behind the scenes of the passkey creation process, where the magic really happens.

Stay ahead of security news with Tech Today, delivered to your inbox every morning.

Read Entire Article