With all the buzz about Passkeys recently, I found myself pushed toward something I know nothing about. Is it some magical thingy that will secure my accounts on the Web? Unfortunately, marketing buzz and lack of factual information made it even harder to know anything.
I hope this guide will help someone to make heads and tails from all this madness.
First, let’s introduce the main hero: Fast Identity Online (FIDO)1 introduces itself via:
The FIDO Alliance is an open industry association with a focused mission: authentication standards to help reduce the world’s over-reliance on passwords. The FIDO Alliance promotes the development of, use of, and compliance with standards for authentication and device attestation.
Amongst the members of the alliance, we can find each of the FANG companies, many banks, password-manger companies, and a few different government organizations. The list consists of different bodies that should be interested in internet security.
However, I failed to find any NGOs on the list.
Web Authentication (aka WebAuthn)2 is a standard for passwordless authentication using asymmetric cryptography. The standard proposes replacing standard password-based authentication with exchanging public cryptographic keys. The user maintains ownership of the private key he generates on the Client Device (phone, hardware keys, etc.). The service provider (known here as Relying Party) receives a public key during registration. When the user wants to authenticate, the server sends a challenge to the Client Device.
It’s the same mechanism we’ve used for years with SSH keys. The server doesn’t need to bother with keeping and securing secrets (like passwords), as the public key is both the public part (think of username) and the secret part.
The term Passkey was first introduced by Apple just a few years ago3. The idea was to reuse WebAuthn and replace the Client Device with an Apple Device. The secret key is stored in iCloud and available on all other devices signed in the same Apple ID. But it was a relatively silent feature until recently when Google added it natively to Chrome and Android4.
So, Passkeys are an implementation of WebAuthn.
Finding user-experience videos was the easiest part here. Everyone seems so proud of how seamlessly it works in their ecosystem:
You can also see a live demo on the Web.
Let’s go to the details since we’ve got the basics out of the way. In this chapter, I’ll use the term WebAuthn instead of Passkey since it’s the technology underneath. One thing to keep in mind: I’ll use “client device” and “authenticator” interchangeably. The RFC allows for dedicated devices (connected via USB or Bluetooth) and for software to be used as authenticators.
The following descriptions will also be very high level. I don’t aim them at developers of WebAuthn solutions, as they should go straight to the RFC.
Registration under WebAuthn consists of generating a unique key pair and sending the public one to the server.
Some additional notes here:
- The Client Device should sign the sent public key with its own Attestation Certificate5. The certificate is used to attest to the manufacturer and its capabilities. The device can also self-attest using the private key.
- The RFC allows for generating keys using the most popular algorithms.
- The unique key pair is not shared between services. The device can generate many certificates for each service, so you can still have multiple accounts for shitposting on Twitter.
As we see, the private key stays with the user, and it’s his job to backup and sync it. The service with which the user creates an account knows only about the public key - and that one can be shared unencrypted anywhere. To the best of my knowledge6, it’s still impossible to generate the private key with the public one alone.
The RFC defines the entire registration ceremony but doesn’t limit how it should be presented to the user. One important thing to remember is that the exchange happens with the browser/OS as a middleman. The UI is not to the webmaster’s7 liking - the site just requests the exchange from the browser and then receives the public key. Think of getting access to the user’s location - it’s an API, but the consent happens in the browser.
First, the server generates a challenge - most likely a big random number. The client device then signs it with the private key. Then the server validates the signature - as it is possible only with the public key.
The cost of Passkeys
WebAuthn is a questionable standard. It removes almost all risks from the service provider and puts all responsibility on the user. Since the keys are just strings, nothing stops us from keeping them anywhere. We already do this - maintaining our SSH or GPG keys is something we do every day. However, this does not apply to the mass public. I can’t imagine a grandma being tasked with ensuring she will never lose this file. This is where companies came in.
As mentioned above, Apple and Google are trying to become the guardians of private keys. At first, though, it sounds great - if it’s in Google Account or Apple iCloud, it will be stored and synced automatically. But after some thinking, it’s not a good idea for the majority of people.
First of all, it’s not safe. Reddit is flooded with worried users after iCloud lost their files or photos. Google is known to block accounts out of the blue. Losing access to an image of a dog may be sad, but it’s not the end of the world. But what will happen when your internet identity becomes locked instantly? You break your phone and suddenly discover all those keys are gone. You just need to forget your iCloud password, and if the backup email is secured with a passkey, you are out of luck8. No food delivery, no bank - not even Twitter to cry about it.
And what if you want to use different ecosystems at the same time? iPhone with Safari and Chrome on the desktop? That’s what the majority of people are doing. Technically nothing is stopping all providers from creating some data exchange protocol. However, the data should be end-to-end encrypted, so any automatic job between the servers is out of the question. Moreover, the thought of your confidential data flowing randomly on the internet should worry you.
And what if you want to use an alternative Operating System? You would be at the mercy of your browser. But let’s say you are a total neckbeard and don’t use any of those major browsers - then you have no chance to log in to a passkey-authenticated service.
Those risks may be removed in the future as all significant password managers are either working on or already supporting passkeys.
I am waiting for an open solution that will give me the authority to manage and sync passkeys. BitWarden may be one, but I’d much prefer password store to support it.9
An X.509 Certificate. ↩︎
but I am not a security expert. It may also be that such methods exist but are not known to the public. Governments hate encryption in citizens hands. ↩︎
Or application designer. I’ll use only Web as an example in the future to simplify it, but the same applies to any other application using WebAuthn. ↩︎