Why Passkeys Will Be Simpler and More Secure Than Passwords

Apple has unveiled its version of passkeys, an industry-standard replacement for passwords that offers more security and protection against hijacking while simultaneously being far simpler in nearly every respect.

You never type or manage the contents of a passkey, which is generated when you upgrade a particular website account from a password-only or password and two-factor authentication login. Passkeys overcome numerous notable weaknesses with passwords:

• Each passkey is unique—always.
• Every passkey is generated on your device, and the secret portion of it never leaves your device during a login. (You can securely sync your passkeys across devices or share them with others.)
• Because passkeys are created using a strong encryption algorithm, you don’t have to worry about a “weak” password that could be guessed or cracked.
• A website can’t leak your authentication credentials because sites store only the public component of the passkey that corresponds to your login, not the secret part that lets you validate your identity.
• An attacker can’t phish a passkey from you because a passkey only presents itself at a legitimately associated website.
• Passkeys never need to change because they can’t be stolen.
• Passkeys don’t require two-factor authentication because they incorporate two different factors as part of their nature.

After a test run with developers over the last year, Apple has built passkey support into iOS 16, iPadOS 16, macOS 13 Ventura, and watchOS 9, slated for release in September or October of this year. These operating systems will store passkeys just as they do passwords and other entries in the user keychain, protected by a device password or passcode, Touch ID, or Face ID. Passkeys will also sync securely among your devices using iCloud Keychain, which employs end-to-end encryption—Apple never has access to passkeys or other iCloud Keychain data.

Best of all, perhaps, is that Apple built passkeys on top of a broadly supported industry standard, the W3C Web Authentication API or WebAuthn, created by the World Wide Web Consortium and the FIDO Alliance, a group that has spent years developing approaches to reduce the effectiveness of phishing, eliminate hijacking, and increase authentication simplicity for users. Apple, Amazon, Google, Meta (Facebook), and Microsoft are all FIDO board members, as are major financial institutions, credit card networks, and chip and hardware firms.

Many websites and operating systems already support WebAuthn via a hardware key like the popular ones made by Yubico. You visit a website, choose to log in using a security key, insert or tap a button on the hardware key, and the browser, operating system, and hardware key all talk together to complete the login. A passkey migrates the function of that hardware key directly into the operating system—no extra hardware required. Websites that already support hardware-based WebAuthn should be able to support passkeys with little to no effort, according to Apple.

Before we get started, note that Apple writes “passkey” in lowercase, an attempt to get us to use it alongside password, passcode, and passphrase as a common concept. Google, Microsoft, and other companies will offer compatible technology and may also opt for the generic passkey name. While new terminology can cause confusion, “passkey” is better than the more technically descriptive “multi-device FIDO credentials,” which doesn’t exactly roll off the tongue.

Let’s dig in to how passkeys work.

Passkeys Bring the Benefits of Public-Key Cryptography to Everyday Logins

Passkeys rely on public-key cryptography, something we’ve been writing about at TidBITS for nearly 30 years. With public-key cryptography, an encryption algorithm generates a secret that’s broken into two pieces: a private key, which you must never disclose, and a public key, which you can share in any fashion without risk of exposing the private key. Public-key cryptography underpins secure Web, email, and terminal connections; iMessage; and many other standards and services.

Anyone with a person’s public key can use it to encrypt a message that only the party who possesses the private key can decrypt. The party who has the private key can also perform a complementary operation: they can “sign” a message with the private key that effectively states, “I validate that I sent this message.” Crucially, anyone with the public key can confirm that only the private key’s possessor could have created that signature.

A passkey is a public/private key pair associated with some metadata, such as the website domain for which it was created. With a passkey, the private key never leaves the device on which it was generated to validate a login, while a website holds only the corresponding public key, stored as part of the user’s account.

To use a passkey, the first step is to enroll at a website or in an app. You’re likely familiar with this process from any time you signed up for two-factor authentication at a site: you log in with existing credentials, enable 2FA, receive a text message or scan a QR code into an authentication app or your keychain (in iOS 15, iPadOS 15, and Safari 15 for macOS), and then verify your receipt.

With a passkey, the process is different. When you log in to a website offering passkey authentication, you will have an option to upgrade it to a passkey in your account’s security or password section. The website first generates a registration message that Apple’s operating systems will interpret—it happens at a layer you never see. In response, your device creates the public/private key pair, stores it securely and locally, and transmits the public key to the website. The site can then optionally issue a challenge for it and your device can present it to confirm the enrollment.

On subsequent visits, when you’re presented with a login, your iPhone or iPad will show the passkey entry in the QuickType bar and Safari in macOS will show it as a pop-up menu. In both cases, that’s just like passwords and verification codes today. As with those login aids, you’ll validate the use of your passkey with Touch ID, Face ID, or your device passcode, depending on your settings.

Behind the scenes, your request to login via a passkey causes the site server to generate a “challenge” request using the stored public key. Your device then has to build a response using your stored private key. Because you initiate a passkey login by validating your identity, your device has access to your passkey’s private key when the challenge request comes in and can respond to the challenge without another authentication step. The server validates your device’s response against your stored public key, ensuring that you are authorized for access. If it all checks out, the website logs you in.

A passkey replaces two-factor authentication, and it’s worth breaking down why, as it seems counter-intuitive: how can a single code held on a device provide distinct aspects of confirmation? The rubric for multiple security factors is usually stated as at least two of “something you know, something you have, or something you are.” A passkey incorporates at least two of those:

• Something you know: While commonly thought of as a password, the “know” part is really any fixed piece of information you possess. Think of a 20-character randomly generated password stored in your password manager. Do you “know” that? Yes, in the sense that it’s retrievable exactly as entered.
• Something you have: Because passkeys are locked to devices, you prove your possession of a device by unlocking the passkey: no device, no passkey.
• Something you are: Although passkeys don’t require biometric authentication using Face ID or Touch ID, it’s an option. Apple always lets you use a device passcode to backstop Face ID or Touch ID, so it’s a blurred line with “something you know” compared to a dedicated biometric device with no fallback option.

Think for a moment about the advantages here. A passkey:

• Resists phishing: As with passwords and verification codes, your device will only present a passkey in QuickType or as a pop-up menu option when on a website’s specific domain associated with the passkey. An attacker can’t fool you into entering a passkey on a deceptive site, as can be done with a password.
• Prevents reuse of a stolen key on other accounts: Because each passkey is unique to its associated website, even if the site suffers a security breach, the only credential that can be stolen is your public key. That public key is useless to help a thief log in as you at another site as they lack your private key to answer the login challenge.
• Blocks damage from malicious code injection on a website you visit: A malicious party can often “inject” malicious JavaScript onto an otherwise benign page. It has happened at times even to major websites, usually due to poorly vetted malicious ads delivered automatically through self-service advertising networks. A website that falls prey to just a front-end attack on its HTML and scripts wouldn’t allow the attacker to produce a valid challenge request for your device’s passkey. The site would also have to suffer from a back-end compromise of its server code for account information to be at risk, at which point the site’s data is probably fully compromised anyway.
• Blocks guessing, identity searching, brute force: Because every passkey has a super-complex secret, an attacker can’t successfully guess or brute force your access to a site.
• Eliminates 2FA hijacking: Because passkeys don’t have a second factor, they aren’t vulnerable to SMS hijacking and interception, site impersonation and phishing, and other techniques to acquire a second factor.

Apple stores each passkey as just another entry in your keychain. If you have iCloud Keychain enabled, the passkeys sync across all your devices. (iCloud Keychain requires two-factor authentication enabled on your Apple ID; Apple hasn’t said if passkeys will replace its internal use of 2FA for its user accounts.)

You can share a passkey with someone else using AirDrop. This means you have to be in proximity to the other person, another element in security. The details are shared through end-to-end encryption, allowing the private key and other data to be passed without risk of interception. Apple hasn’t provided much more detail than that AirDrop sharing is an option, so there may be other provisos or security layers.

Because passkeys replace passwords and a second factor, you may be reasonably worried at this point about losing access to your passkeys if you’re locked out of your Apple ID account or lose all your registered devices. Apple has several processes in place for recovering Apple ID account access and broad swaths of iCloud-synced data. For an Apple ID account, you can use Apple’s account recovery process or an account Recovery Key. For iCloud data, if you’ve enabled the friends-and-family recovery system, iCloud Data Recovery Service, you can use that to re-enable access. After you recover account access, Apple has an additional set of steps that enable you to retrieve iCloud Keychain entries: it involves sending a code via SMS to a registered phone number and entering a device passcode for one of the devices in your iCloud-synced set.

This is all a fabulous reduction in the potential for successful attacks against your Internet-accessible accounts. But there’s more: Apple isn’t building yet another walled garden. Instead, passkeys are part of a broad industry effort with which Apple says its implementation will be compatible.

Passkeys Are an Industry Standard, Not a Proprietary Technology

Apple built its passkey support on top of the previously mentioned WebAuthn standard, which describes the server side of how to implement a Web-based login with public-key cryptography. FIDO created standards for the client side of that equation and calls the combination of its protocol and WebAuthn FIDO2. Apple developed its own client-side approach that’s compatible with standard WebAuthn servers and should be interchangeable with other companies’ rollouts of passkeys. Google, Microsoft, and Apple made a joint announcement in May 2022 committing to this approach, too.

In Apple’s passkey introduction video for developers, engineer Garrett Davidson emphasized Apple’s commitment to compatibility, saying:

We’ve been working with other platform vendors within the FIDO Alliance to make sure that passkey implementations are compatible cross-platform and can work on as many devices as possible.

He then demonstrated using a passkey on an Apple device to log in to a website on a PC, showing how a QR code could be used to enable a passkey login to one of your accounts on a device or browser that’s not connected to your existing devices or ecosystem.

Here’s how you might log in to a passkey-enabled account on someone else’s PC using your iPhone with your passkey as the authenticator. During the login, you can opt to add a device instead of entering a passkey or other authentication in the browser. The website’s server generates a QR code that includes a pair of single-use passwords—they’re generated just for that login and used in the next step for additional validation. (Note that the device with the browser could be any passkey-supporting operating system and device. The authenticating devices might be limited by Apple or other companies to a smaller set, much like you can only use an iPhone to confirm Apple Pay in Safari on a Mac, not a Mac with Touch ID to confirm Apple Pay from an iPhone.)

The PC in our example also starts broadcasting a Bluetooth message that contains the information needed to connect and authenticate directly with the server. Scan that QR code on your iPhone, and the iPhone uses an end-to-end encrypted protocol to create a tunnel with the PC’s Web browser using the keys shown in the QR code. (This encrypted connection isn’t part of the Bluetooth protocol, by the way, but data tunneled over Bluetooth; Bluetooth doesn’t incorporate the necessary encryption strength.)

This Bluetooth connection provides additional security and verification by offering out-of-band elements, or details that the PC isn’t presenting to the device that’s providing authentication—here, your iPhone. Because Web pages can be spoofed for phishing attacks, the Bluetooth connection provides a device-to-device backchannel for key details:

• Server addresses: The QR code doesn’t tell the iPhone what server (or list of servers) it can connect to for the actual passkey connection. That prevents a browser from providing malicious information.
• Key validation: The successful creation of an end-to-end encrypted two-way session over Bluetooth using the keys in the QR code enables the iPhone and PC to confirm that the QR code the browser delivered and the iPhone scanned are identical. (Apple hasn’t yet provided full details on this stage. The operating system clearly generates the QR code based on a request from the browser, and the browser can’t sniff the Bluetooth connection. So a front-end attack that displayed a malicious QR code wouldn’t work, as the PC and iPhone communicate without the browser in the loop.)
• Proximity: Connecting over short-range Bluetooth demonstrates, with confidence, that the PC and iPhone are near each other.

This broad device and platform compatibility lets you maintain the same degree of passkey security and simplicity without downgrading to a weaker method for login when accessing your account using other people’s devices. Whenever there’s a way to force a weaker login method, malicious parties will exploit that via phishing, social engineering, or other interception techniques. (Providing a second factor via an SMS text message versus a verification code is a prime example of a weaker backup approach that has been exploited.) In fact, until passkeys can be used exclusively, password-based logins will have to remain available, and they’ll remain vulnerable.

There might be some usability hiccups as passkeys roll out, but they shouldn’t be widespread. It’s possible, for instance, that some WebAuthn server components will need to be updated or that Apple will have to add more edge cases to its framework to encompass how things work in the wild.

But imagine a world in which you can securely log in to websites using any current browser on any device running any modern operating system, without having to create, remember, type, and protect passwords. It’s relaxing just to think about.

The main question that remains unanswered is how portable passkeys will be among ecosystems: can I use iOS and Android and Windows and share a passkey generated on one among all three? Given that Apple has built an AirDrop-sharing method for passkeys, I hope FIDO’s broad compatibility includes sharing passkeys among operating systems, too.

A Return to Security through Proximity

Passwords have provided an uneasy security compromise since their introduction decades ago when multi-user computing systems began to require protection. Passwords are patently imperfect, a relic of an age when physical proximity provided the first level of protection, something rendered moot by the Internet.

In an effort to answer some of the weaknesses in a password system, two-factor authentication was grafted on to require that you had something besides a password, something that required holding or being near an object to validate your right to log into a computer, service, or website. But because 2FA starts with an account password and uses a second method that can be subject to compromise or phishing, it remains a patch applied to a damaged wall.

The passkey is a modern replacement for passwords that rebuilds the security wall protecting standard account logins. Proximity—in the form of the device that stores your passkeys—is a powerful tool in reducing account hijacking and interception. Passkeys may seem scary and revolutionary, but they’re actually safer and, in some ways, a bit old-fashioned: they’re a bit of a throwback to a time when having access to a terminal provided proof you were authorized to use it.