Can you even "own" a passkey?

Passkeys are finally mainstream and the specs for passkeys and WebAuthn just reached level 3 at the W3C. Yet education on passkey's security properties, proper implementation, and how they work has not reached a ubiquitous threshold in the software development community. A question I recently answered in a chat started with:

Seeing lots of passkey being pushed by various services. Is there a reasonable way to “own it”? Is it still very bad at a full loss recovery?

Extension based passkeys generally have a way to export them. Whether it is in a format that can be imported to the same service or another is an active area of standardization and adoption.

Check out

• FIDO Alliance's CXF Specifications page
• Credential Exchange Format Proposed Standard
• Credential Exchange Format Errata

Platform synced passkeys can be exported too — at least if you're on Apple Passwords or Google's Password Manager. Windows Hello is device bound and the Microsoft Password Manager has no published export method documented at this time and they instead do all passkey assertion operations in the cloud with confidential compute. Google uses confidential compute too for passkey assertions through Chrome outside of Android and iOS.

This is likely due to the European Union's Digital Markets Act enforcement targeting smartphone interoperability where Apple often gets slapped for non-compliance and Google follows.

There was a time when Microsoft had a Windows Phone, but thanks to Google breaking and denying any interoperability with societal infrastructure like YouTube, we have less platforms now to compete or support in this world.

Without an active mobile operating system, Microsoft hasn't been compelled to offer passkey interoperability.

Every passkey has its own private key. You won't find a competent authenticator (device, platform, cloud, or virtual) using the same private key across origins or user handles — consequently, the public key cannot be correlated across origins or user handles. If one passkey is removed, the rest are intact. If one and only one is exported, the rest are not.

Good consumer Relying Parties will let you register multiple passkeys and allow any of them to be used while authenticating, and should not follow up by asking for a TOTP like Amazon. I did use my fingerprint or PIN after all.

Meanwhile OneLogin (an enterprise identity provider) thinks WebAuthn (including passkeys) should be accessed like "which OTP token provider are you using today?" in a dropdown.

Passkeys have not been competently implemented across consumer and enterprise applications… maybe some day people will care more.

While platforms and device bound passkeys do user verification with a PIN or biometrics or even system password, virtual authenticators through extensions like LastPass report user verified without actually verifying the user. This is why we can't have nice things.

Whether you have the meticulous nature to add multiple passkeys stored across different platforms and devices to every account you create is a challenge that most will not try.

I highly recommend creating multiple passkeys for your "root" accounts that have access to just-about-everything-else through account recovery. If Amazon thinks you are your gmail account, then have redundant access to your gmail through several passkeys and recovery codes.

Suppose you're on computer that doesn't belong to you. Normally you might transcribe the password from your password manager (or from memory) into the other computer. What if there are only passkeys, are you short on luck? Thankfully not if the computer has Bluetooth LE and public internet access. With hybrid authentication your phone can authenticate you securely on that other computer through a cloud assisted communication channel established over a QR code and a BLE advertisement.

Whose cloud?

Got an iPhone? It's Apple's cloud. Got one with Android that has access to Google Play Services? Then Google's.

The specification only has these two options. You cannot own or self-host the hybrid authentication experience.

Actually, the spec has a way if you keep reading. If you buy a domain name like qz2ekwmnd332c.info (owned by the HID Global Corporation), you could implement your own hybrid authentication using a 16 bit integer that hashes into this domain, in this case 0x0100. I also see that 0xffff has been bought too.

While it is unreasonable to own and operate your own hybrid authentication infrastructure, or develop your own authenticator using a chip like the NXP EdgeLock® SE050—

Focus on the scope a normal person would expect on owning a passkey.

Sure…

Can you "own" a password?

What happens when you give your password in the clear to someone else, including the person or thing that will let you in?

What happens when it exists tangibly outside of your head in a note pad? You can own the notepad, but someone else can find it and copy it out.

Passwords are serializable. They are necessarily transcribed, copied, and shared physically or over the network — whether over an encrypted channel or in the clear. Without meaning to, they can be reused across contexts too. The password to your bank shouldn't be the same as your Facebook password, yet reality shows people do that. This makes them weak. And I'd argue, this makes passwords impossible to "own."

Once possibly known by a third party, it should be rotated. Because passwords can't be owned, they must be disposable.

Passkeys rely on public key cryptography. You don't share your private key to authenticate yourself to another party. But, like the notepad of passwords, you can own the thing the private key is on. Yet the moment the private key is exported, we run into the same thing.

It's like a mathematical constant. The moment it is serializable, isn't bound to one single physical thing, it can't be owned anymore.

Read more on the Free Speech flag and Illegal numbers on Wikipedia.

Also, a private key is a mathematical constant.

Assuming that timing analysis, power analysis, voltage glitching, cryptographic or protocol flaws, and any other way of coercing an otherwise secure device to reveal its private key, you could "own" a passkey if its private key cannot be exported.

In other words, the argument states: if you had a magic box that can't be opened or copied and it had unguessable number inside, that you also own the number in the box.

In cryptography, we often rely on the probability that selecting a magic number from a sufficiently large set is negligible to assume a cryptographic construction is secure.

Like passwords, we rotate private keys as soon as possible when there is a risk of it being known by a second or third party.

Sometimes, just to be safe, our servers rotate their private keys on a schedule.

When Certbot grabs a new Let's Encrypt certificate, it mints a new private key for each certificate request. This works fine for HTTPS, it might not for other protocols.

While servers may do that, to address their risk profile, passkeys shouldn't be rotated on an arbitrary schedule — only in response to a risk in regards to the holder of the private keys, the password manager.

Sometimes passwords are forgotten and passkeys are lost. Most consumer sites let you recover from credential loss using less secure channels like SMS OTP or a magic link over email. Others may have a lockout period with scheduled alarms to undo the pending reset or afterwards to prevent account hijacking.

These recovery mechanisms are necessary for the fallible human. While they don't invalidate the security a passkey offers, they do mean that theoretically owning a passkey has less strength than you might assume.

At least platforms like Microsoft, Apple, and Google necessarily understand that multiple passkey registration is expected. I recommend setting up a synced platform passkey, a device bound passkey (like a YubiKey with PIN), and if you use a third party provider like 1Password, a passkey there too to your "root" accounts that can recover every other account.

By construction, passkey leaks are so unlikely that the only way the common person will get in trouble is if they exported their passkeys and put it on a public pastebin, or downloaded an info stealer that hijacks their browser extensions, or a supply chain attack got into against a password manager's Chrome extension.

For the last reason, I personally will not use passkeys from a password manager that operates within the browser process or otherwise has its storage accessible outside of a robust platform-enforced trust chain. In other words, I'll stick with Apple's Passwords and use hybrid authentication (with QR codes) where needed.