What the Heck are Passkeys? And Should I Be Using Them?

Passkeys are a brilliant idea — a rare win, in that they are more secure than signing in with a password and (generally) easier to use as well.

A very short summary is that when signing in with a passkey, the authentication happens on your own device. So if I’m signing in via passkey, my device essentially asks, “hey user, prove to me that you’re the person who is allowed to unlock this device.” Once I do that (e.g., by PIN or fingerprint), the message the device sends to the other institution is basically, “this device has verified the user, and they have access to the passkey for this account.” So it has benefits such as:

• No reusable secret information is being transmitted.
• The institution doesn’t have to store any secret information (i.e., password).
• It has the potential to eliminate the risk of somebody guessing/stealing your password, because somebody would have to be in possession of your device and be able to convince the device that they’re you.
• It’s resistant to MFA-code phishing (such as in the John/Rachel example), because there’s no code to share in the first place.
• It’s also resistant to fake-website phishing attempts (e.g., somebody buying Vamguard.com and putting a site up that looks exactly like Vanguard, with a login page to collect login credentials), because passkeys are tied to a specific domain, so they won’t work on look-alike sites like Vamguard.com.
• It’s (usually) easier to sign in with a passkey than with a password, and passkeys eliminate the hassle of resetting passwords due to forgetting.

How Do Passkeys Work?

When trying to understand how passkeys work, it’s helpful to keep in mind the goal. The goal is to have a system in which a user can sign into a website or app without having to transmit any secret information. All of the secret stuff lives on the user’s own device. And everything that gets transmitted, and any login-related info that’s stored on the website’s server is safe if anybody else sees it.

But how can you log into a website without sending them your password or some other secret information? That is, if you don’t have to transmit any secret information to the website (i.e., if only “public” information is necessary), how can the website make sure that nobody else can sign into your account? To create a system that works in such a way requires fundamentally rethinking the entire process.

And that’s what passkeys do. They solve those problems.

And broadly, the idea is that the “proving you’re who you say you are” process happens locally, on your own device.

We’ll go through it step-by-step (i.e., what happens when you create a passkey, and then what happens when you use that passkey to log in).

But first we have to start with one piece of jargon.

What is a “Challenge?”

In order to understand passkeys, you have to understand what a “challenge” is.

You can think of a challenge as a formalized “who are you, and please prove it” request.

An “unsigned challenge” is what the server sends to you. For example, if you’re on your bank’s website and you click “log in with a passkey” or if you’re already signed in and you click a link to create a new passkey, your bank will send an unsigned challenge to your browser.

And what your device will eventually send back to the server is a “signed challenge” (along with some other information). We’ll get to how a challenge is satisfied (“signed”) in a moment.

For now, one thing to know about a challenge is that each one has a unique identifier (e.g., challenge #203SNA30DNDQ), and each challenge is one-time-use-only. This is a critical security feature. It means that if somebody managed to spy on your transmission (and were thus able to view the signed challenge that you send to the server in order to log in), they would not be able to simply copy that signed challenge and send it to the server themselves in order to log into your account. The server would say, “sorry, this challenge has already been used,” and the fraudulent login attempt would be rejected.

Magic Pen and Magic Magnifying Glass

With “challenge” defined, let’s take a brief detour for an analogy, to explain the other major parts of the passkey ecosystem.

Imagine you have a magic pen. It writes in normal-looking ink. But you also have a magic magnifying glass. When this magic magnifying glass is used to examine something that was written with your magic pen, the ink glows sparkly purple. When it looks at anything written with any other ink (i.e., not written by your magic pen) the ink just looks normal.

There’s no way to “reverse engineer” the magic pen from the magic magnifying glass. In other words, if somebody were to have the magnifying glass, there’s no risk that they could create a copy of your magic pen.

So you give magic magnifying glasses to all of your friends. That way, any of them can see whether a message was really written by you, with your magic pen. Fun! And you can give out as many of these magnifying glasses as you want, because again, nobody can recreate your magic pen just by having one of these magnifying glasses.

What Happens When You Create a Passkey

When you’re signed into a website or app, and you choose to create a new passkey, the server will send your device a new unsigned challenge.

Your device takes that unsigned challenge and creates three new things:

1. A private key.
2. A corresponding public key.
3. A credential ID. This is just a public identifier for the passkey (e.g., your new passkey is passkey #22093948310930).

The private key is the secret thing. The private key lives on your device (or is synced securely across your devices via your Apple/Google/Microsoft account) and is never sent to the server. The private key is your magic pen, and it can be used to sign a challenge.

The public key is unique and linked to the private key. The public key is the magic magnifying glass. It’s essentially a testing tool. When somebody has the public key, they can use it to test the signed challenge to see if it was signed with the private key (magic pen) that corresponds to that public key (magic magnifying glass).

An important point here is that there is no way for somebody to look at a given public key and determine the corresponding private key. So it’s absolutely no problem if somebody were to intercept your public key. Just like with the magnifying glass, you could give out your public key to as many parties as you want, with no security risk.

After your device creates these three things (private key, public key, credential ID), it uses the newly-formed private key (magic pen) to sign the challenge. And it sends the public key, the credential ID, and the signed challenge back to the server. It does not send the private key to the server.

The server then stores the public key and credential ID and associates them with your specific user. (Remember, you’re already logged in before beginning the process of creating a passkey, so it already knows who you are.)

So at this point:

• You have a private key (magic pen) stored on your device.
• And the server has a public key (magic magnifying glass) and a credential ID, both of which are now associated with your user.

What Happens When You Log in with a Passkey

When you initiate the process to log in with a passkey, your device first checks: “Do I have a passkey saved for this app/website?”

This step is itself a valuable security measure. It means that if you ever accidentally visit a fake website (e.g., you fell for the first part of a phishing attempt, clicked the link in the email, and are now on usbamk.com rather than usbank.com), your device will immediately stop the process. It doesn’t have a passkey associated with this domain. Disaster averted. (Though seriously, please don’t click that link in the first place.)

If your device sees that it does have a passkey for the website/app in question, the website/app sends an unsigned challenge to your device.

Your device then goes through some process to satisfy itself that you are you. This might be entering your device PIN or providing some biometric identifier (e.g., fingerprint).

Once your device is satisfied that you are you, it uses the stored private key to sign the challenge.

And your device then sends the signed challenge, the credential ID, and your username to the server. Again, it does not send the private key. (Also note: your PIN/fingerprint is never transmitted to the server either.)

The server then:

1. Checks that the username provided exists in the system,
2. Checks that the credential ID a) exists in the system and b) is linked to the username in question, and
3. Uses the stored public key (magnifying glass) that’s associated with the credential ID in question to test the signed challenge, to make sure that it was signed by the appropriate private key (magic pen).

If all three of those things proceed happily, you’re signed in.

Passkey Limitations

An important issue to be aware of is that, at least as of right now, when websites let you use passkeys, they usually let you sign in using the passkey or a password. So the weak password/stolen password path of attack still works. Ideally we’d see websites that let you implement passkeys and then make it impossible to sign in with a traditional password. But so far, that sounds scary to many users because passkeys are unfamiliar. Hopefully that changes over the coming years as more and more people use them.

In addition, there’s messiness where everybody wants you to use their passkey ecosystem. So if you’re browsing on Chrome on an iPhone, and you visit a website for which you already have a passkey set up (via Apple), Chrome might prompt you to create a new one — which can feel very confusing. Fortunately, you can usually create a bunch of passkeys for the same website, so you can have one for each device/browser combination, for each website.