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

Google passkeys are a no-brainer. You’ve turned them on, right?
Aurich Lawson | Getty Images

reader comments
267 with

By now, you’ve likely heard that passwordless Google accounts have finally arrived. The replacement 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, this E2EE 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., which is a shortcut to, 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.

The passkey section of showing a passkey had automatically been added to a Pixel 7.
The passkey section of showing a passkey had automatically been added to a Pixel 7.

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 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 updated to indicate that a new passkey had been created.

Article Tags:
Article Categories: