How passkeys work: Going passwordless with public key cryptography

For the last five years, the FIDO Alliance — led by Apple, Microsoft, and Google (with other companies in tow) — has been blazing a trail toward a future where passwords are no longer necessary in order to login to our favorite websites and apps.

This so-called passwordless future is based on a new form of login credential known as the passkey, which itself is largely based on another technology — public key cryptography —  that’s been around for decades. 

Why the big push to ditch passwords? And why now? Bottom line: We humans are partly to blame.

Much as we try to protect ourselves, we somehow keep getting fooled into divulging our passwords to malicious actors. This can happen in various ways, including phishing and smishing. But malvertising has been creeping back into the conversation as a technique that hackers use to seduce us into visiting legitimate-looking websites.

For 20 years, tech vendors and IT departments everywhere have tried in vain to educate end-users about the various threats (and the threat actors behind them) and the best practices — many of them common sense — that are necessary to protect ourselves. Yet here we are in the 2020s, and rarely does a week go by without the announcement of some major breach that started with sloppy credential management. 

Passkeys are a bit like passwords in that there’s a secret involved. But unlike with passwords, where you have to submit that secret to a site or app each time you sign in, with passkeys, your passkey secret never gets shared with these websites and apps (collectively referred to as “relying parties”). In fact, given the way passkey secrets are automatically created and stored, most users don’t even know what their secrets are or where to find them. And if you don’t know what your secrets are or where to find them, not only won’t you be sharing them with your relying parties, you won’t be inadvertently sharing them with malicious actors either.

In other words, the tech industry found a way to keep us from being our own worst enemies.

The registration ceremony 

So far, in this six-part ZDNET series on how passkeys work, I’ve offered a brief explanation of public key cryptography, walked you through the process of how to discover if a relying party supports passkeys and what an authenticator is, and how it gets complicated once you trigger the creation of a passkey. In this installment, we’ll go behind the scenes of the passkey creation process (aka, “the registration ceremony”) where the magic really happens. 

When we last left off, I had just triggered the passkey registration ceremony for Shopify.com. Working with passkeys requires the presence of an authenticator, and, using MacOS as the operating system and Chrome as my browser, I demonstrated how the user is confronted — quite unintuitively — with a variety of authenticator options. 

Also: What really happens during a passwordless login?

(Note: The word “authenticator” here is used in a passkey context; it does not imply the use of a mobile app like Google’s authenticator app that’s dedicated to the generation of timed one-time passcodes (TOTPs). In my case, Bitwarden’s password management browser extension is serving as my authenticator. None of these choices should be construed as endorsements. I could have just as easily relied on a different website, operating system, browser, and authenticator. While the registration ceremony is generally the same from one setup to the next, there will be some nuanced differences if you’re using different technology.)

Before Bitwarden’s password manager can automatically take priority over other available authenticators, it must be registered with Chrome as a WebAuthn-compatible credential provider. WebAuthn is the official name of the World Wide Web Consortium’s (W3C) standard for passwordless authentication on the web. As standards go, the W3C WebAuthn standard is technically independent of the passkey standard, which itself is governed by the FIDO Alliance. The passkey standard is, therefore, one, but not the only, WebAuthn-compatible passwordless means of Web authentication. Also, in order for mobile apps to work with passkeys, those apps must support the WebAuthn standard as well.

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

For Bitwarden to register itself with Chrome, the user must first login to the Bitwarden extension. It’s important to note that logging into Bitwarden is different from unlocking it. In addition to registering the extension as a credential manager with Chrome, the act of logging into Bitwarden activates the extension and prepares its vault for on-demand creation, storage, or recall of any credentials. However, once the extension is activated, it still must be unlocked just prior to those moments when you want to create, store, or recall a credential. 

Proponents of passkeys and other WebAuthn-compatible credentials like to say they’re a standard method for web authentication using biometrics (fingerprints or face recognition) or PINs. That’s because you typically need a biometric or PIN to unlock your password manager at those same moments. That’s why, in the screenshot below, the active (and registered-with-Chrome) Bitwarden sprang to life at the moment I tried to create a passkey for Shopify.com and asked for a PIN to be unlocked. 

Once Bitwarden — my authenticator of choice — is unlocked, it checks to see if it already has a set of credentials (for example, a username and password) for the current relying party. Since I already have an account on Shopify.com and I’m using Bitwarden’s password management capability to keep track of my username and password for it, the password manager wants to know if it should associate the passkey with that same record (as shown below) or if it should create a new record. It would not be unusual for a user to have multiple records for the same site. For example, if a user has multiple Gmail accounts, they should keep a separate entry for each in their password manager. In the case of my test, I have only one Shopify account.

Once the user decides whether to pair the new passkey with their password manager’s existing record or to create a new record, the public key cryptography part of the process begins as the three steps described below.

Public key process

Step 1: Create and store a new public/private key pair and credential ID: The authenticator creates and stores a public/private key pair as well as a unique credential ID that’s specific to both the end user and the public/private key pair. Given how users can register multiple passkeys with the same relying party, each passkey is assigned a unique authenticator-generated non-human-readable credential ID. In cases where a third-party password manager like Bitwarden, 1Password, or LastPass is designated as your authenticator, the authenticator creates a new record (essentially, the credential) for the relying party in a secure software container (commonly referred to as a vault) and associates the newly created public/private key pair and credential ID with that record. Along with those and other fields of data stored in this record, it also stores the unique, end user-specific non-human-readable user.id that the relying party included as a part of the PublicKeyCredentialCreationOptions mentioned in Step 2 below. In doing so, the relying party-generated user.id is now inextricably coupled with the authenticator-generated credential ID.
In cases where the user chooses an authenticator that’s associated with the underlying operating system (e.g., Apple’s iCloud Keychain), that authenticator will likely use the local system’s security hardware (e.g., Secure Enclave on Apple hardware and trusted platform modules or TPMs on Windows) for passkey storage. If a roaming authenticator like a Yubico Yubikey or Google Titan physical security is the user’s chosen authenticator, the passkey will be stored on the roaming authenticator’s secure hardware.

Step 2: Transmit the newly created public key and credential ID to the relying party: At the moment you’re on a website like Shopify.com and click a button to create a passkey, the site (the relying party) responds with a time-sensitive offer of passkey configuration instructions called PublicKeyCredentialCreationOptions (as explained in Part 3 of this series) and one of those options is a random string of characters referred to as a “challenge.” Now comes the time for the authenticator to prepare its response to that offer with its own package of information called the PublicKeyCredential. Among the various bits of information contained within that package is the newly created public key, the authenticator-generated credential ID, a copy of the aforementioned challenge, and various other bits of information to indicate that the relying party’s original passkey creation options were followed. The authenticator digitally signs the entire package with the newly created public key’s matching private key and hands its response to the browser, which then delivers it to the relying party’s server.
Once the relying party receives the public key and a copy of the challenge that was effectively signed with the matching private key, the relying party’s original offer cannot be reused to create another passkey. For example, if the offer was somehow intercepted and replayed by a threat actor, the relying party would detect the attempt to re-use the already spent (or timed-out) challenge and abort that attempt. Additionally, just before the relying party pairs the new public key and credential ID as a passkey with the appropriate user account (see step 3 below), it uses the newly received public key to integrity-check that the returned copy of the challenge matches the original challenge and that it was signed with that public key’s matching private key.
One of the core tenets of public key cryptography is that a public key can be used to validate actions taken with its matching private key and vice versa.      

Step 3: The relying party makes a record of the public key and credential ID: This is another of those moments to which the magically secure properties of passkeys are anchored. Remember: With passkeys, the secret (which is the private key from the public/private key pair) is never shared with the relying party (neither during registration nor during subsequent authentications).

Similar to Shopify’s workflow for the passkey registration ceremony, most of today’s passkey enrollments are triggered after you are already logged in to the relying party’s site or app. So, the relying party already knows exactly which user account to indelibly pair with the newly received public key. From this point forward, the only user who can use that passkey to sign in (aka: authenticate) is the user in possession of both the unique credential ID and the public key’s matching private key. In fact, to the extent that the credential ID uniquely represents a combination of the specific user and a specific passkey credential, it can theoretically be used in place of a username during future login attempts.
Also: Do your favorite sites even support passkeys? 

Additionally, thanks in part to the way the relying party’s ID (the “rpId”) is integrity checked during both the passkey registration and authentication ceremonies, the passkey can never be used to sign into any other legitimate or malicious relying party, thereby eliminating one of the biggest scourges of passwords — the sharing of passwords across multiple relying parties. Nor will the user ever be required to reveal the actual secret (the private key) to any party, legitimate or not — thereby neutralizing attempts by threat actors to phish, smish, or malvertise you for your secret credential.

Registration success

Once the new public key credential is successfully enrolled with the relying party, the authenticator’s pop-up should disappear, and the relying party should present a new page or screen that reflects the successful registration of a passkey. As shown below, Shopify.com updated two parts of its security settings page. The first of these (see the red arrow) says, “A passkey was created. You can now use your passkey to log in. This passkey is synced across devices logged into the same platform.”  

What this means is that if your choice of authenticator supports a syncing capability and you’re using that authenticator on multiple devices, then the private key component of the passkey will be synced to those other devices. In my case, where I’m using Bitwarden as my authenticator and credential manager on both my MacBook and my Android-based phone (and both copies of Bitwarden are associated with the same underlying Bitwarden account), the new passkey will be synced to my Android device. This way, I can use the same passkey to log in to Shopify from either my MacBook or my phone. 

However, if your choice of authenticator doesn’t support syncing, as is the case with roaming authenticators, then the passkey is essentially married to that device. 

Also: If we want a passwordless future, let’s get our passkey story straight

The green arrow (screenshot above) shows Shopify’s actual record of the newly created passkey. It provides some information about when and how the passkey was created, along with a link to remove the passkey. Passkey management and deletion are covered in Part 6. The reason it says “Passkey #1” is that Shopify (and most but not all relying parties) allows you to create multiple passkeys. For example, for the same relying party, you might want to create a syncable passkey that you manage with your password manager and then another non-syncable passkey that goes with your roaming authenticator. For Shopify, the second passkey would be named “Passkey #2” and so on. Some relying parties allow you to give your passkeys more meaningful names. Shopify isn’t one of them.

As the final step of Shopify’s passkey registration ceremony, I received an email confirmation notifying me of the update to my account, as shown below. 

An email confirmation is not an official part of the standard passkey registration ceremony, and not all relying parties send one. In this case, Shopify is also offering you some account recovery codes. If you somehow lose all of your credentials (username, password, passkeys, etc.), such recovery codes may be the only way to regain account access. For more information about the urgency of downloading and safeguarding recovery codes, be sure to read ZDNET’s Top 10 Passkey Survival Tips. 

Now that we know how to create and enroll a passkey, in the next part of this series, I’ll take a close look at the authentication ceremony — when a passkey is used to sign into a relying party. 

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

How passkeys work:  Overview | Discovery | Selection | Registration | Authentication | Deletion 

READ MORE HERE