Update: After reading more of the spec authors’ comments on open-source Passkey implementations, I cannot support this tech. In addition to what I covered at the bottom of this blog post, I found more instances where the spec authors have expressed positions that are incompatible with open-source software and user freedom:

When required, the authenticator must perform user verification (PIN, biometric, or some other unlock mechanism). If this is not possible, the authenticator should not handle the request.

This implementation is not spec compliant and has the potential to be blocked by relying parties.

Then you should require its use when passkeys are enabled … [You may be blocked because] you have a passkey provider that is known to not be spec compliant.

I suspect we’ll see [biometrics] required by regulation in some geo-regions.

I’ll leave the rest of the blog post as it was below, but I no longer think Passkeys are an acceptable technology. The spec authors’ statements, refusal to have a public discussion about the issues, and Passkey’s marketing, have all shown this tech is intended to support lock-in to proprietary software. While open source implementations are allowed for now, attestation provides a backdoor to lock the protocol down only to blessed implementations.

So long as the Passkey spec provides the attestation anti-feature, Passkeys are not an acceptable authentication mechanism. As a result, I’ve deleted the Passkeys I set up below in order to avoid increasing their adoption statistics.

Two years ago, Ars Technica published an article about how Passkeys are finally here and provide a better experience than passwords. To be honest, the article was pretty poorly written and I didn’t really understand it. The worst part is the article makes it sound like it requires a lot of Big Tech Proprietary Magic:

Just like the FIDO authenticators stored on these MFA devices, passkeys are invisible and integrate with Face ID, Windows Hello, or other biometric readers offered by device makers. There’s no way to retrieve the cryptographic secrets stored in the authenticators short of physically dismantling the device or subjecting it to a jailbreak or rooting attack.

That smells really bad, and made me pretty skeptical of this authentication method. Unlike the article’s author, I don’t trust Big Tech to control my entire digital life. I want to be able to own and back up my data independently of what Big Tech decides to do, especially for something as important as service logins. But, I filed it away as something to keep an eye on later, when the rough edges are smoothed out and adoption is a little higher.

A couple weeks ago, Microsoft published a blog post about increasing Passkey adoption. They say password-based authentication is on its way out and Passkeys can provide a better, more secure login experience. Okay, I’m still skeptical, but it sounds like it’s finally time to dig in and figure this out for myself.

First I need to figure out what Passkeys even are. Microsoft’s docs say:

With passkeys, you can sign into your Microsoft account using your face, fingerprint, or PIN.

Hmm. My desktop computer does not have a camera or a fingerprint reader, and a PIN sounds an awful lot like a password. I’m not really sure how this could work for me. Let’s go see what Google says:

With passkeys, you can securely sign in to your Google Account using just your fingerprint, face, screen lock, or security key.

Again, I don’t have a camera or a fingerprint reader. I’m extremely skeptical that Google’s login website can interact with my Linux desktop’s XFCE screensaver via Firefox, or how that could provide any benefit. I don’t know what a security key even is. I’m no further along to understanding what a Passkey is. Let’s try the official Passkey website from FIDO:

A passkey is a FIDO authentication credential that allows a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern).

… What? Stop. What are you talking about? My Linux desktop doesn’t even have a lock screen. Are you going to somehow notice my screensaver exiting to permit a login? How can that possibly work? Are they trying to tell me that their fancy new login system only works on certain proprietary operating systems? Really?

If you’ve read all the above and feel like Passkeys are load of proprietary crap from Big Tech Companies, then you’re in the same boat I was until a few days ago. That’s exactly what the marketing is trying to tell you. But I have good news. They’re actually really simple:

Passkeys are a public/private keypair authentication system. That’s it.

Ignore all the lock screen and biometric stuff that the marketing is screaming at you. You can generate Passkeys on your computer just like we’ve been doing with SSH keypairs for decades. You can store those keys however you like, so long as you have a way to feed them into your web browser to provide to the service at login-time. You can copy your Passkeys around as much as you like, to any device you like. You can share them with friends.

Despite what the marketing tells you, they don’t have to be tied to biometrics or devices. That’s just an implementation detail of how you access the private keystore on what will probably be the most common devices: phones and computers running proprietary OSes. But you don’t have to do that.

I’ve got this working on my Linux desktop and laptop using KeePassXC, which is provided by my distribution. I use it with Firefox with the official KeePassXC browser plugin, so Firefox can retrieve the Passkey from my password database and provide it to the website. After enabling some settings, KeePassXC provides a nice UI for creating a new Passkey when you are registering at a website, and retrieving it when you log in. If I wanted to share a Passkey with a friend, I could use KeePassXC’s export feature to give the key to my friend to import it into their password manager. The KeePassXC password database is just a file on disk. I store it in a Git repo, which I then clone to my laptop, so I can use the exact same Passkeys on my laptop. I also copy the password database to some offline storage for backup. Now I can be sure that I will have access to my logins regardless of what happens to my devices, and no matter what the Big Tech companies decide to do with my information. No proprietary software. No phones. No lock screens. No biometrics.

Cool. That nicely addresses all my concerns with Passkeys, and I’m now happy to start using them. So what’s the deal with all the Passkey marketing focusing on phones and biometrics?

It turns out that’s where the complicated (and pretty nifty!) feature of Passkeys comes in. It’s possible to access the private keystore on one device, from another device, at login time without copying Passkeys around between the devices. Your login attempt on the new device somehow (e.g. via a URL provided in a QR code, or local Bluetooth, or some Big Tech Cloud Provider Magic) prompts a connection to the device with your private keystore. The device with the keystore authenticates the user (e.g. via biometrics or a lock screen) before allowing access to the keystore. After authentication, it provides the key directly to the login service in the background, and you’re logged in on the new device, without ever having to enter a password. It’s likely that this will be the most common method for using Passkeys, so that’s why the marketing focuses so much on it.

That’s pretty cool! But it’s highly complicated and often dependent on Secret Big Tech Cloud Service Magic. In theory, I think you could provide this service from a device you control, but I bet in practice that’s actually impossible. The spec authors very clearly think of non-Big Tech implementations as an annoyance. But the good news is this stuff is entirely optional: if you’re willing to manage your private keys manually by copying your keystore around, then there’s no need to use the Big Tech Cloud Service Magic stuff. Many services also allow you to have multiple Passkey public keys associated with your account, so you could even have one keypair that you manage manually and keep in an offline backup for safety, and another keypair that uses the Big Tech Magic for convenience.

So cool, Passkeys are actually really simple, and do provide some benefits over passwords. Now that I actually understand what they are, I’m going to start using them. If the awful marketing hadn’t gotten in the way, I probably would have done so a long time ago.

I do have one big, lingering uncertainty. On KeePassXC’s Github issue tracker, one of the authors of the Passkey spec wrote:

To be very honest here, you risk having KeePassXC blocked by relying parties

I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails, but this statement really puts the Passkey spec authors in a bad light. It should not be possible to block me from logging into a service because they don’t like the password manager I use. Between the fact that the spec author sees this capability as a good thing and the Big Tech-focused marketing, this really makes me think that the Passkey spec authors do not have users’ best interests in mind. They clearly think using this technology to lock users into Big Tech ecosystems is a feature, and other uses are an annoyance that they have to grudgingly support. It’s not a great look.

That kind of attitude makes me uninterested in going “all in” on Passkeys. I will be retaining my passwords in case the Passkey people go off the deep end and start requiring garbage like TPM in order to restrict what users can do with their own data. Hopefully the spec author is just a little too close to the issue and communicated badly. Time will tell.

Anyway, it’s been quite an adventure managing to figure out what Passkeys actually are behind the truly awful marketing. I hope this article clears things up for other folks who are similarly skeptical of Big Tech.