What is a Passkey? - Computerphile

Have you noticed that more and more you go onto a website and you try and log in and it pops up with some message about a pass key and says do you want to add a path key for this site?

>> I have and I'll be honest I have not got a clue what that is >> and that what might be one of the problems. I think no one really knows what they are. So I thought we could look at pass keys today. What is a pass

key? Is it good that your browsers are

key? Is it good that your browsers are forcing them upon you in some sense? And

you know, there are people that say that pass keys are going to completely replace passwords and there are people that say they aren't. What's that about?

Let's let's explain that.

>> And I think we'll probably come to this, I'm guessing, but um if I've set up a pass key on my laptop, how do I use that on my phone?

>> You can't.

We've done loads of videos on the past on passwords, so we're not going to talk about them today. Let's just focus on a couple of the real problems with passwords that are around even still in you know 2025 2026 passwords are misused

by a lot of people right they choose weak passwords they reuse passwords in different websites despite you know many many hours of sitting through cyber security training telling you not to do this and the reason that's a problem is

that if someone breaks into one website they then have access to all the other websites that share that password.

They're also very very vulnerable to fishing. So, if you go on a website and

fishing. So, if you go on a website and there's been some problem that means you're actually on an attacker's website, but you see the normal login prompt, you might be tempted to put your username and password in there and then

they've got your credentials, right? So,

passwords are hard to remember. They're

often easy to guess. People use them badly and they can easily be fished, right? But, you know, not not everyone,

right? But, you know, not not everyone, you know, I would like to think that I'm fairly impervious to fishing, but of course, I can't guarantee that I'm always going to make the right decision all the time. It's situational, isn't it? You you're busy, something asks you

it? You you're busy, something asks you for your password, and you just start typing.

>> And so, we introduced two-factor authentication as a way to kind of circumvent this. But two-factor

circumvent this. But two-factor authentication has its own problems. So, for example, you might just get a simple yes, no pop-up on your phone. You're not

quite sure what it's about. Don't click

yes is my big advice if you're not sure.

So the first thing to know about pass keys or web offn which is the um underlying technology is that it's not based around hashed passwords right it's

based around public key cryptography. So

let's just very briefly recap that as well. You have two keys a public key and

well. You have two keys a public key and a private key. And the whole point of public key cryptography is you shouldn't be able to find out the private key or calculate it if you've been given the

public key. So maybe I have a public key

public key. So maybe I have a public key here and I also have a private key here and I can send that public key out to various people to do various things with

and I can hold my private key back and never give it to anyone and you you cannot given that I've given you the public key tell me what my private key is.

>> Anything encrypted with the public key can only be decrypted with the private key. Is that

key. Is that >> yes but we're not talking about encryption today right? So so we're talking about digital signatures. Let's

suppose you have some kind of token that you want to sign and verify with the public key. You sign this with the

public key. You sign this with the private key. So you there's an algorithm

private key. So you there's an algorithm to sign it and you sign the token with the private key. Only I can do that because I'm the only one with the private key and then you can verify this

with the public key, right? And you get a yes or no answer that says that token is valid and has been signed by Mike, right? And this is used all over the

right? And this is used all over the internet, for example, in TLS handshakes. Now, the overall goal of a

handshakes. Now, the overall goal of a pass key is that instead of typing your password into a website, they send you a token, you sign it with your private key, they verify that with your public

key, and let you in, right? That's

that's that's the overall intuitive what's going on. Now, it gets a lot more complicated than that because you got to think about who's got the token, where did it come from, where are these stored, who sent them and generated

them. But that is broadly speaking what

them. But that is broadly speaking what a pass key is. So, how does this work?

Well, let's imagine we've got three different kinds of people. I'm going to I'm using all the colors today. I'm

really, you know, I'm going for it.

>> Um, so you have something called a relying party, which I'm going to summarize as RP. The relying party is the website or other entity you're trying to authenticate on, right? So,

you've added a pass key or you're going to add a pass key to let's say an online shop. They are the RP in this situation.

shop. They are the RP in this situation.

And most of this happens on the web, right? It's possible to use this

right? It's possible to use this elsewhere, but this is mostly web. The

client is the device or the browser or whatever it is software you're using to talk to the RP and to eventually authenticate you.

>> That's at your end, the user.

>> That's at your end. Yeah. So, this is over on the server. This is you over here. And the client will be your

here. And the client will be your browser. And finally, at the back, we

browser. And finally, at the back, we have something called an authenticator, which I'm not going to be able to fit in this box. I'm going to start small.

this box. I'm going to start small.

Hooray. Right. You can't read it, but I but I did I did finish the word. Now,

the authenticator is the thing that actually does the signing with the private key. You know, intuitively

private key. You know, intuitively what's going to happen, and we have to think about why we would do it this way, is that the RP is going to hold your public key. They've got that from

public key. They've got that from somewhere. The authenticator is going to

somewhere. The authenticator is going to hold the private key, and then there's going to be messages going back and forth with this token to to to give you access to various websites and things like this. We could dive into the whole

like this. We could dive into the whole of Web Orn and maybe we can do a video at a later date where we go into much much more detail about the actual protocol. Maybe we even demonstrate some

protocol. Maybe we even demonstrate some creating some pass keys and see how they work. Right? But for this video, let's

work. Right? But for this video, let's keep it a little bit higher level and talk intuitively about what this is doing that passwords do not do. So, what

is this token? Right? That's the first question. So, do you remember that that

question. So, do you remember that that scene in in in the Bean movie, right?

The Mr. Bean movie where he's waving his ticket in first class, his first class ticket, and he's really proud of himself. That's a little bit like the

himself. That's a little bit like the signed token, right? You've got a token, you're waving it around, and people are letting you into things. But you got to think if I've signed a token and you get hold of it, what's to stop you then taking that token and going off

somewhere else >> waving it around.

>> Yeah. So in actual fact, we need to guarantee that this token changes every time. We can't just say, let's say, sign

time. We can't just say, let's say, sign your name because you could then get a copy of that sign name and then use it on a different website or use it on a different website. So this token has to

different website. So this token has to be fresh, right, is the word we would use. It has to be new. Okay, so that's

use. It has to be new. Okay, so that's one thing to think about. So at the beginning of a request, an RP is going to generate a token and send it to the client and say, "This is the one I want you to sign." Not just some generic one,

this specific one for this specific login session. And once that expires,

login session. And once that expires, you're going to have to go again with a different token. Right? So that's

different token. Right? So that's

something to bear in mind. Let's talk

about the generation process. When you

go on a website and it says, "Would you like to add a pass key?" What actually happens? Well, the first thing is that

happens? Well, the first thing is that the RP, which is the website, will ask your client, I want to generate a pass key, and they're going to send various information

over to the client. This is going to hold various bits of information, but the the the first things it's going to include are the ID of the domain that you're registering. So, let's say, you

you're registering. So, let's say, you know Amazon.co.uk

know Amazon.co.uk

right? It's very important that tokens work on only a single website for the obvious reason that you don't want to be using them on the wrong website. You

also don't want some other website like mike specialcial amazon.co.uk to be able to get an official signed token because then I could man in the middle and I could I could start trying to pretend to

be you. So they have an ID, they have

be you. So they have an ID, they have some user information and they have other kind of info that I'm going to just sort of wave away on things like how they expect this to be used, whether they expect the user to have to verify

themselves and things like this. The

client is going to forward some of this information and some new information on to the authenticator, right? So, for

example, they're going to send a hash of the client data that's going to include things like the generation challenge token. I'm going to write it in purple

token. I'm going to write it in purple actually. So, this actually I forgot

actually. So, this actually I forgot this. The the RP does generate a a token

this. The the RP does generate a a token specifically for the creation process as well as the signing process. So, this

data gets built into this client data as well as the RP information, right? RP

ID, which is, you know, the domain ID.

What is the authenticator? We talked

about this. This is the browser. This is

some website that you're trying to create a pass key on. What is this?

Well, it could be a few different things. It could be your Windows Hello,

things. It could be your Windows Hello, right? Windows Hello, you know, login

right? Windows Hello, you know, login with your face, login with a PIN, that something Apple have an equivalent. Um,

it could be your, you know, UB key or some other two-factor authentication key. It could be your mobile device.

key. It could be your mobile device.

Right? It's a device that holds the ability to authenticate these messages to sign them with the private key. And

the way this has been designed is this is kind of modular. So you can have your browser have pass keys from your password manager or from your operating system or from your phone. The idea

being that it's more versatile. You can

store these in different places. So this

goes to the authenticator and the authenticator generates our public and private key pairs. Right? Public not in green. Not in green. The authenticator

green. Not in green. The authenticator

is also going to produce an ID for this particular pass key, right? Which is

just this one pair of public and private keys that's going to be used for this specific website from this specific client. And this is called something

client. And this is called something called context binding. So the idea is these are now in intrinsically linked.

Right? You can't use this private key to sign a different client's request to another.

>> Oh, so this is when I asked about um made one on my laptop. Can I use it on my phone?

>> No. Right. You can't do that unless the authenticator is your password manager which is portable. So there are some kind of portable implementations of this but there are also some that are not

portable like your laptop. It creates an ID which I'm going to have to I'm going to have to use the last color right like this is the ID for this particular set of credentials right and this goes back

this way. So we we we pass this back and

this way. So we we we pass this back and we pass this back and eventually what happens is this public key and the ID

get stored on the relying party right so now your website stores this right this private key and the public key and the well not the public key is less important this private key and the ID

get stored on the authenticator so that is the generation process now what happens when we actually want to log into a website so normally you would go in and you would type in your user name and you type in your password and there

will be an authentication mechanism there. So, I'm going to clone this piece

there. So, I'm going to clone this piece of paper and I'm going to use it. In

fact, I can I can do this. Oh, this is very exciting. There we go.

very exciting. There we go.

>> Right. And I'm going to kind of recreate the parties involved. Our client wants to log us into this RP. Right. Or the

RP.

>> This is another day. It's a new session.

You've you did this all. Yeah.

>> Yeah. Yeah. Okay.

>> So, the RP is going to send a request.

It's going to get a signature from this authenticator and that's going to include a new clean token that's not been seen before. It's going to include

a RP ID, right? How many times am I going to write ID in this one? And then

it's going to include other information like whether the user needs to be verified. I have to do something like a

verified. I have to do something like a biometrics. And it's going to also

biometrics. And it's going to also provide credential IDs. Credential IDs.

So don't forget that this one has a which which one ID ID and a public key.

Now you know you might have multiple pass keys on a website because you've come at it from multiple clients.

Actually you can have multiple with the same client, right? It's a bit confusing because you can't usually have multiple passwords. So that's a bit odd. But it

passwords. So that's a bit odd. But it

means that you might have more than one in here. So it sends a list of things

in here. So it sends a list of things it's expecting it you might use. And so

hopefully you'll have at least one of those things. So this gets forwarded on

those things. So this gets forwarded on from the client to the authenticator.

Remember they're kept sort of distinct.

This ID goes with this one here, right?

Which is this private key down here. Now

the client sends a hash of the client data. So I'm just going to say client

data. So I'm just going to say client data. That's going to have things like

data. That's going to have things like the original token in it. It's going to have things like the origin requesting URL. So I'm going to write them in. So

URL. So I'm going to write them in. So

token should have done that in purple.

Uh URL.

It's actually called um an origin, but I'm just going to write URL or domain just for the sake of simplicity. Let's

take a moment to talk about this context binding. This RP sends an ID. This

binding. This RP sends an ID. This

client also knows where the request came from because it's seen the URL come in, right? You know, it came from a

right? You know, it came from a JavaScript running on a website we're visiting. So, there are lots of

visiting. So, there are lots of opportunities to say, hang on a minute, this is the wrong website, right? This

is not the right ID or not the right URL. I don't want to sign this

URL. I don't want to sign this authentication token because it might be an attack. So the client where the

an attack. So the client where the origin of the request and the ID for this particular pass key don't match, it doesn't have to respond. It can just say no, we're not doing that. Right?

Similarly, the authenticator is going to actually sign not just the challenge but also the original ID of this website, right? And information on the client as

right? And information on the client as well. And that allows us to ensure that

well. And that allows us to ensure that this is the exact correct pass key that was agreed with this original RP via this client and none of these have been changed. Now that's a good thing. It

changed. Now that's a good thing. It

does mean that of course this is a flaky system in the sense that if you lose your client, right, you reinstall Windows or you lose your authenticator, you lose your phone. That's a problem.

The authenticator signs both the client data and various authentication data which will be things like the RP ID and other stuff, right? And I'm just going to draw a big red box around this. This

is the signature calculated by here.

This gets forwarded back to the RP via here and it can verify using this public key right that this is the correct

signature. Now there are loads of other

signature. Now there are loads of other fields that are included. So for example the authenticator keeps a track of how many times it's used this to to log in and that can be used to detect for example if someone's trying to use two

authenticators to do the same thing and stuff like this. But it's essentially an authentication system based around public key. You have a list of some

public key. You have a list of some number of IDs and private keys. The

public keys were originally shared with whatever the system is you're trying to authenticate on. And when they challenge

authenticate on. And when they challenge you with a token, you check all the domains match and then you sign that and send it back. They can then verify that using public key and let you in. Let's

talk briefly about how this is different to passwords. This can't be fished very

to passwords. This can't be fished very easily at all because if you send me an email and say go on this website and log in, the website URL is not going to be this URL. None of these are going to

this URL. None of these are going to match. This system is not going to

match. This system is not going to activate for you. Right? These are just going to reject the suggestion. It can't

be replayed. Right? So, one problem you would have with that token we talked about earlier would be you you you see a token that I've signed, you grab that signature, and you just use it again later to log me in. that can't be done

because this token is generated fresh every time and will time out very very quickly. So it deals with a with various

quickly. So it deals with a with various problems of passwords that we have but particularly the fishing one right and in some sense it's also more convenient right you you know you can't remember

all your passwords you use a password manager what this does is say do you want to use your pass key yes please and then it just does that and you don't have to type anything in right you might have to type a pin or a bit of

biometrics as the kind of user verification side of this which is encouraged but theoretically it's more convenient to use and this I think is why there are some people who say that

this is now the future of authentication right the idea is passwords have all these weaknesses this deals with many of those weaknesses and it's slightly easier to use why wouldn't this just be

the the future right and that's probably true but I would also say that you have to now explain to most of the world what this is and you can see this diagram is

not absolutely trivial and I've cut a lot of detail out people are not famously that interested Ed in taking on things they don't understand. Right?

When you go on Amazon or another website and you say and it says add a pass key and you go okay and you click yes and then your password manager pops up and your Windows Hello also pops up and says what kind of pass key would you like and

you don't even know what a pass key is.

You're just going to quit out of that and do something else. Right? And the hu and the biggest problem that I can see is what happens when you lose one of these two things. Right? Same problem

with two-factor authentication. If I'm

using an authenticator on my mobile phone and the client is my browser and then my phone gets smashed, right, or stolen and I get new phone now, how do I log into here, right? Not with that pass

key. I can tell you that, right? Because

key. I can tell you that, right? Because

I'm never getting it back. The answer is with a password, right? At least today that's what the answer is, right? And so

you don't solve the problem of fishing by adding another authentication mechanism, but also still having the password that can be fished, right? So

we we're not solving the problem yet. In

the future, you could imagine you might solve the problem by completely replacing passwords. And that I think is

replacing passwords. And that I think is the question, but for me hasn't been answered yet. Right? I'm sure if you

answered yet. Right? I'm sure if you know the answer to that question, put it in the comments, right? I want to see it. But I think it's it's a great idea

it. But I think it's it's a great idea and I think it will be a really big thing. I think we need to tell everyone

thing. I think we need to tell everyone what it is. We need to explain to them why it's a useful thing to do. And we

need to find ways for people not to put all their eggs in one basket, lose their phone, lose their laptop, lose the pass key, right? And that way, um, it could

key, right? And that way, um, it could be a really big deal.

>> Does that mean if somebody gets your phone, they could potentially just be have access to all these passwords?

>> That's a good question. So, if you didn't have user verification on and you didn't have a password on your phone, absolutely. Yes. Right. So if you left

absolutely. Yes. Right. So if you left your part if you left your laptop unlocked and you had pass keys on it but didn't require user verification then yes but most websites enforce and

most clients enforce user verification.

What that means is that Windows Hello won't just send the pass key. It will

ask you for a PIN or it will ask you for a biometric. It would be hard for you to

a biometric. It would be hard for you to use to trick my phone into getting it to divulge pass keys and sign these requests. Right? It's not impossible but

requests. Right? It's not impossible but then it's a lot easier to fish a password. So I guess that it is a step

password. So I guess that it is a step in the right direction. There are

obviously huge benefits to knowing more about AI, programming, and computer science in general, but where do you start? Why not try Brilliant for a

start? Why not try Brilliant for a personalized interactive and beautifully designed journey through myriad topics? These are fantastic, and

myriad topics? These are fantastic, and they're adding new courses all the time.

As you can see, this is learning by doing, by solving problems, and being encouraged along the way. This could be the start of something huge. Maybe the

launch pad of a new career for you or for someone to who you gift a Brilliant subscription. Can you picture that? Now,

subscription. Can you picture that? Now,

to learn for free, go to brilliant.org/computile

brilliant.org/computile or scan that QR code on screen or click the links in the description, the comments, all the usual places.

Brilliant's also giving our viewers 20% off an annual premium subscription, which gives you unlimited daily access to everything.