Google passkeys are a no-brainer. You’ve turned them on, right?

By now, you’ve likely heard that passwordless Google accounts have finally arrived. This alternative for passwords is known as “passkeys.”

There are many misconceptions about passkeys, both in terms of their usability and the security and privacy benefits they offer compared with current authentication methods. That’s not surprising, given that passwords have been in use for the past 60 years, and passkeys are so new. The long and short of it is that with a few minutes of training, passkeys are easier to use than passwords, and in a matter of months—once a dozen or so industry partners finish rolling out the remaining pieces—using passkeys will be easier still. Passkeys are also vastly more secure and privacy-preserving than passwords, for reasons I’ll explain later.

What is a passkey anyway?

This article provides a primer to get people started with Google’s implementation of passkeys and explains the technical underpinnings that make them a much easier and more effective way to protect against account takeovers. A handful of smaller sites—specifically, PayPal, Instacart, Best Buy, Kayak, Robinhood, Shop Pay, and Cardpointers—have rolled out various options for logging in with passkeys, but those choices are more proofs of concept than working solutions. Google is the first major online service to make passkeys available, and its offering is refined and comprehensive enough that I’m recommending people turn them on today.

First, it helps to know exactly what a passkey is and how it works. Apple provides a helpful description here of the technical underpinnings of passkeys:

Passkeys are built on the WebAuthentication (or “WebAuthn”) standard, which uses public key cryptography. During account registration, the operating system creates a unique cryptographic key pair to associate with an account for the app or website. These keys are generated by the device, securely and uniquely, for every account.

One of these keys is public, and is stored on the server. This public key is not a secret. The other key is private, and is what is needed to actually sign in. The server never learns what the private key is. On Apple devices with Touch ID or Face ID available, they can be used to authorize use of the passkey, which then authenticates the user to the app or website. No shared secret is transmitted, and the server does not need to protect the public key. This makes passkeys very strong, easy to use credentials that are highly phishing-resistant. And platform vendors have worked together within the FIDO Alliance to make sure that passkey implementations are compatible cross-platform and can work on as many devices as possible.

The FIDO specs require that whatever syncing mechanism a user elects (be it from Apple, Microsoft, Google, or a third party) it provide end-to-end encryption the way iCloud Keychain and password syncing with browsers currently do (on Chrome, the E2EE password syncing must be turned on). This means that the private key is unknown to the cloud provider. The private key resides on the device and can only be accessed by unlocking the device using either a unlock PIN, a fingerprint or face scan. The private key never leaves the trusted user devices, except as an E2EE blob synced through one of the big three or, soon, a third party such as 1Password.

Google account passkeys support enough platforms that there’s no single way to use them. The way a person who primarily uses Android and Linux logs in will look different and use a different flow than a person who uses all Apple platforms or a person who uses iOS or Android with Windows. There’s no way to list step-by-step instructions for all platforms in one article. This primer instead uses a mix of devices and OSes—specifically a Pixel 7, an iPhone 13, a ninth-generation iPad, a ThinkPad running Windows 10, and a MacBook Air—with the goal of at least touching on the basic workings of all of them.

WTF is this passkey doing on my Pixel?

By the time I woke up on Wednesday—the day Google rolled out passwordless Google accounts—my Pixel 7 already had a passkey automatically created. I didn’t notice until I accessed g.co/passkeys, which is a shortcut to myaccount.google.com/signinoptions/passkeys, the page Google has installed for managing account passkeys. To my surprise, the key was already there. Since my account was enrolled in Google’s Advanced Protection Program (APP), this new key appeared immediately above two-factor authentication (2FA) keys that APP requires for bootstrapping new browsers that log in.

As the image indicates, I was using Chrome on the MacBook Air to access the page even though my preferred browser these days is Firefox. The reason: Firefox does not yet support passkeys on macOS, although that will change, likely sooner than later. I ultimately decided to continue using Safari for the rest of the process because passkeys created using that browser on macOS and iOS are automatically synced through the iCloud Keychain. For the time being, passkeys created with Chrome and Edge on Apple platforms are not.

Accessing the same g.co/passkeys page in Safari, I scrolled to the bottom and clicked “Create a Passkey” and received a dialog box providing a short explanation of passkeys. From there, I clicked the “Continue” button. The next screen that appeared explained I was saving a passkey that would be stored in iCloud. Once I clicked “done,” the passkey section of myaccounts.google.com updated to indicate that a new passkey had been created.

The myaccount.google.com page. From here, click “Create a passkey.”

The myaccount.google.com page. From here, click “Create a passkey.”

Click “Continue” on the next screen.

Click “Continue” on the next screen.

The myaccount.google.com page. From here, click “Create a passkey.”

Click “Continue” on the next screen.

Click “Continue” again.

Click “Continue” again.

Voila. A passkey managed by the iCloud Keychain has been born.

Voila. A passkey managed by the iCloud Keychain has been born.

Click “Continue” again.

Voila. A passkey managed by the iCloud Keychain has been born.

Don’t fear the QR code

To access the myaccounts.google.com page on the MacBook Air, I authenticated with a password, just as I always do. The passkey that Google automatically created on my Pixel 7, however, gave me an alternative way to authenticate. Instead of entering a password into the login page on the Mac, I could click “Try another way” immediately below and to the left of the password field. From there, I was given the option to use a passkey. I then chose “iPhone, iPad, or Android device,” received a QR code on the next screen, and used my Pixel 7 to scan it. I chose “Passkey,” which was presented immediately below the scan, followed the prompt, and finally provided a fingerprint.

The Google login page loaded into Safari on the MacBook Air. Click on “Try another way.”

The Google login page loaded into Safari on the MacBook Air. Click on “Try another way.”

On the next screen, click “Use your passkey.”

On the next screen, click “Use your passkey.”

Then choose “iPhone, iPad, or Android device” and click “Continue.”

Then choose “iPhone, iPad, or Android device” and click “Continue.”

On the next screen, click “Use your passkey.”

Then choose “iPhone, iPad, or Android device” and click “Continue.”

A QR code will appear on the next screen. Scan it with the Android device that automatically received the account passkey.

The QR code as viewed through the Pixel camera. Press “Use passkey.”

Android will then show a dialog screen. Press “Allow.” On the next screen (which, for security reasons, Android will not allow to be screenshotted), provide a fingerprint scan.

This process is known as cross-device authentication. The QR code is displayed by the device a user wants to log in to and is scanned using a device that already has a passkey. The end result—logging Safari in to my Google account—is precisely the same whether I authenticate with a password or through cross-device authentication using the passkey on my Pixel device.

A quick detour: Careful readers may notice that the images above show the QR code with no redaction or obfuscation. In many cases, it’s highly unsecure to publicly display a QR code used for authentication because anyone else can scan it and access the cryptographic secret that allows the untrusted device to log in. For a couple of reasons, that’s not the case with QR codes associated with passkeys. For one thing, the trusted device scanning the QR code (in my case, the Pixel 7) must be physically close enough to the untrusted device to connect over Bluetooth. That’s a requirement readers would be unable to satisfy. And for another, once the untrusted device (in my case, the MacBook Pro running Safari) connects, the QR code is invalidated.

With a passkey now stored and synced by iCloud, using them on my iPhone and iPad—or any other Apple device connected to the same iCloud account—was a snap. It means I can now use the iPhone or iPad for the same kind of cross-device authentication provided by my iPhone. When both Chrome and Edge loaded on the login page on either the iPad or iPhone, it allowed me to skip the password (i.e., try another way) and instead use the passkey managed by iCloud.

I then fired up Chrome on my ThinkPad and visited the login page for my Google account. This time, I used the newly created passkey available on my iPhone to authenticate. The process was almost identical to the one earlier for using the passkey on my Pixel to authenticate to Safari on my Mac.

Enter your username into the login page.

Enter your username into the login page.

Click “Continue” on the next screen.

Click “Continue” on the next screen.

Enter your username into the login page.

Click “Continue” on the next screen.

Select “Use a different phone or tablet.”

Select “Use a different phone or tablet.”

Chrome on the ThinkPad presents a QR code. Scan it with the iPhone and authenticate using Face ID.

Chrome on the ThinkPad presents a QR code. Scan it with the iPhone and authenticate using Face ID.

Select “Use a different phone or tablet.”

Chrome on the ThinkPad presents a QR code. Scan it with the iPhone and authenticate using Face ID.

There are some major parts missing in the passkeys ensemble. For now, Chrome on macOS needs its own local passkey. Firefox support isn’t yet available on macOS, and I couldn’t get that browser to work on Windows 10, either. Things are even more limited for Android. Currently, passkeys synced by Google don’t work with browsers, but again, that will change soon enough. For now, passkeys can be used as an alternative to flows that would traditionally require the user to enter a password on an Android device (for example, when accessing pages, such as rescuephone, that would normally require a password).

ChromeOS has no support for passkeys at all. This is largely due to the way ChromeOS encrypts data at rest residing on the Chromebook itself, specifically the decryption key being tied to the password. Passkeys are backward compatible, so even if someone logs in to Gmail using passkeys on other platforms, they can use their traditional Gmail password when using their ChromeOS device. Most glaring of all, Linux doesn’t work at all with passkeys.

This lack of seamless integration among OSes and browsers is the result of various players being further ahead or lagging behind their peers. Passkeys are a work in progress with many moving parts. Within a year—and, more likely, much sooner—all the pieces should become available and be assembled in a comprehensive way.

One other common complaint about passkeys is that the required Bluetooth connection when doing cross-device authentication is unreliable and can torpedo the login process. This shortcoming came up in a 2019 article I wrote about Google’s embrace of phone-bound security keys for iPhones and iPads. I didn’t know it then, but the thing that was tripping up the flow was that my iOS device and Mac weren’t connecting properly over Bluetooth. Since then, the standards that make passkeys possible have evolved. Now, they have embraced a “hybrid” approach that uses a combination of Bluetooth and data sent via the cloud. The result has been a reduction in what is sent through Bluetooth to the bare minimum. (As noted elsewhere in this post, people who don’t want to use Bluetooth can authenticate with their normal password and then save a passkey.)

Not just easier… more secure

With a basic primer on using passkeys out of the way, let’s turn our attention to the security of passkeys. Passkeys provide a level of protection not possible with passwords. For one thing, they can’t be phished the way passwords can. Passkeys are underpinned with cryptographic keypairs that reside on each device. There’s no way a user can be tricked into revealing the secret key used for authentication. There’s also no known way to extract these keys from the device, and even if there were, an attacker would need physical access to the device for an extended period. As noted earlier, the QR codes used for cross-device authentication can be used only once, and they expire within a short time when not used. The two devices doing this authentication dance must be nearby. An attacker half a world away, or even in the next town, can’t make any use of them.

Passkeys also automatically include 2FA into the flow and can be modified to provide a third factor for those who want it. Compare that with the flow of traditional 2FA, which most often requires the user to have a password and a physical device. Not only is this inconvenient, but one-time passwords provided by many of the physical devices are phishable.

Some passkey skeptics have expressed concerns about entrusting Apple, Google, or Microsoft infrastructure with the secret key. Some of these critics have gone so far as to say that passkeys are a power play designed to give these companies control of authentication secrets not previously possible.

These claims simply aren’t true. The keys are end-to-end encrypted using the same mechanisms (like iCloud Keychain) that millions of people have used for years. It’s impossible for these companies to decrypt the keys stored on their servers, and even if they could, they’d be unable to use them without close physical proximity to the user device providing the second factor of authentication.

For people who still don’t want one or more Big Tech companies touching their passkeys, they will soon be able to rely on companies like 1Password and Dashlane to do it for them. A 1Password representative said in an email that the company expects to roll out that capability in early June. By September, it will be possible to use a passkey to log in to 1Password (demonstration videos for each are here and here.)

Some people complain about the requirement to provide a fingerprint or facial scan because they don’t want their biometrics shared with third parties. In fact, the biometrics never leave the device. Anyone who currently trusts unlocking their device with a fingerprint or face scan has no reason to feel uncomfortable doing the same thing with a passkey. Additionally, those who don’t trust the use of biometrics can simply authenticate by entering their device unlock password (which just like the biometrics, never leaves the device).

Other critics have also complained that the flow of passkey synchronization represents a step back from the way passwords are synched by browsers. Chrome will sync passwords to any major platform that has Chrome installed. Passkeys, by contrast, are currently synced through the OS. As a result, the passkey created for Chrome on macOS is device-bound, meaning it can’t sync to Chrome on other platforms. This design was a conscious decision by the passkey architects, who concluded that OSes provide a more secure means of moving passkeys from device to device.

I don’t think this is much of a regression of the current state of things. The cross-device authentication process involving QR codes is a one-time requirement. Once completed, the user saves a passkey to the browser or platform being onboarded. This doesn’t seem like any more of a hassle than setting up password syncing on a newly installed browser. And in any event, the limitations here are temporary. The ultimate goal of passkeys is seamless integration across all platforms, browsers, and password managers.

As noted throughout this primer/explainer, passkeys are still in a nascent stage that currently prevents them from living up to their promise. Google’s implementation, however, is far enough along that I feel comfortable recommending people use it. Now that I’ve overcome the initial learning curve, I find them easier to use.

Out of curiosity, I removed my Google account from my iPhone and re-added it. Rather than requiring me to enter my password and provide a physical key (the latter step is necessary because I’m enrolled in the Advanced Protection Program) I had the option to use the passkey that was already synced through iCloud (specifically iCloud Keychain). Four single clicks and a Face ID scan later, I had my Gmail account completely restored.