Implementing Passkeys in Practice - Computerphile transcript

And I thought maybe a nice thing to do would be to actually implement some pass keys. Create one, use it to log into a pretend website and actually sort of see some of the data that's going back and forth. I mean, it is a complicated system, but it also is kind of intuitive what happens, right? I've got a website that I created, one of my classic, unbelievably good-looking, well-designed websites that I like to make, where we have both steps of the process.

We have the creation of pass keys and we have the use of pass keys to log into things. The way that I've coded this up is you can see all the data going back and forth. That that was my whole plan. And so we'll draw out what happens and then we'll look at this and we'll look at the code and we'll see what's going on under the hood. If we just start by looking at just how you create a pass key, right? Or how you your browser and your operating system create a pass key in should we say in combination with the server at the other end.

So you want to log into a website and that website is going to be running some kind of PHP or Node or some other kind of back end that does some code. Let's just say this is the server, right, which in my case is PHP. Now we're over here on the browser and in my case, this is obviously, you know, JavaScript and HTML and things, right? So I'm just going to write JS. Full disclaimer, I neither program in PHP or JS. So you know, I've done my best to kind of haphazardly join this together.

But anyway, let's suppose you log into a website, you type in your username and you type in your password, right? This is what normally happens. And then they've now added this functionality to the website to create a pass key. You that's when you get that prompt, right? You've logged in. Would you like to create a pass key on this website? So the actual request to create a pass key starts with the client on the browser, right?

So they're going to fetch from the server arguments for creation create args. And that's basically saying we want information on the server. What does the server need? Do they need the user to be verified? What kind of um pass keys do they allow? This kind of stuff, right? So this goes off to the server and the server creates those args. A lot of this is just JSON, JavaScript object notation, right? And we'll have a look at this.

This gets sent back to the browser and this is kind of where the pass key actually gets created. So the browser is going to call some JavaScript called navigator.credentials.create, create, right? And this function on any browser, that's what creates a pass key, right? And it needs these arguments to do that, right? So, it takes the arguments about the server. It's going to create a pass key. And this will mean your browser then talks to the operating system or talks to your password manager or talks to your phone depending on what website we're on and what we're using to browse that website.

Right. And that's where the pass key is created. So, this will involve, you know, a TPM. >> That's the trusted platform module. >> Yeah. or an operating system software version or you know a password manager something along these lines. This will create a public and private key pair which will be buried again in JSON and then go back to the server for checks and if the server's happy with it, it will store all this stuff in its database.

That's a B, not a D. DB, right? And then it will respond with okay, right? Or some kind of yeah, good job. You've made a pass key, right? So this is just the creation of a pass key. So I've coded all this up. Let's actually see some of this data, right? Because it is cryptographically complicated, but actually once you see it and you point out the main things, I don't think it's quite as bad as people think. So I've created this demo website.

I've got six buttons. Normally you wouldn't see all the buttons, right? Most of this happens automatically. Most of this happens in one or two steps in the JavaScript behind the scenes. But I wanted to kind of hardcode everything so that you could see each individual step happening. What I've done is I've got this index HTML with all the JavaScript involved. I've got various login and register PHP files that do most of the verification and checking of these credentials.

I got a bit carried away and overengineered it primarily because I wanted to avoid too much library use because to do that if you want to see all the individual stuff you kind of have to do a lot of it yourself, right? Most libraries will do all this in a much better way than I'm doing but they won't show you all the data. So the first thing we're going to do, we just logged onto a website. Our user our username is demo user for this for this example.

And our website is not Amazon or BBC. It's localhost, right? Because it's running on my laptop. And we're going to fetch the create argument. So this is going to ask the server what it's going to need from a set of credentials. So if we click this, this goes off to PHP and returns for us some JavaScript with various combinations of binary data and base 64 and all this other kind of business. But there's a few key things that we need.

The first thing is the ID of the relying party. So that's the website we're on. The username of the user and a challenge and that's basically to stop people from replaying creation things later, right? This challenge is going to be unique to this. So if I click fetch arguments again, it will get a new challenge. So if we go back to our little diagram, we've just created these arguments right here [clears throat] and we've returned the arguments in JSON to our browser.

The browser now needs to create the credentials. So if I create click navigator.credentials.create, it's going to ask the operating system for a pass key. Now my password manager has popped up. I'm not going to use it. And then Windows pops up. Windows has said, "Oh, I've been asked for a pass key for demo user on local host. Would you like to do it?" Now, if I click cancel, it will just return failed. Right? But I'm going to click okay.

I'm going to type in my pin code. It goes off and the trusted platform module on my computer will sign this. Right? And it will different things will happen depending on where you're creating the pass key and the data it returns back is quite complicated right is rather than look at every single field. I wanted to highlight the key stuff. So first of all the client data which is this thing down here. This is just information on what website it is.

What was the challenge right? And you can see that the challenge this challenge GB uh uh GPBQ is actually the same one that was sent earlier on in the fetch argument. So that's almost like a kind of unique ID for >> it's a unique ID, right? And so it stops you let's say sending back to a server a [snorts] challenge like 2 days later or someone else doing it or or you know it stops any kind of situation where some of these messages are being replayed later, right?

Because they have to be new. The attestation data is essentially all the signatures and certificate chains and things involved in verifying that this is a real TPM and it is the one that actually created these credentials. Normally a lot of this attestation is actually ignored by the servers, right? It's not that important. But consider a situation where maybe you're running a bank, right? And you want people to log in, but there you want them only to log in with your official authenticator because you don't want um other random people producing pass keys.

You might verify that it's it's the exact hardware or software mechanism that you wanted inside here. So in this case, so the format is TPM. That means that a TPM was the thing that that created these credentials, right? That's my TPM on my motherboard. I'm not convinced that knew a TPM because it signed this message with SH1 hash right and RSA which is deprecated. Um but for this atstation data that's not not that important >> just to sign it is >> yeah it's signed with the private key it's baked onto the chip right and so that can't be changed and it doesn't matter that we've deprecated uh RSA in some sense or RSA sh1 because there's not a lot we can do right short of replacing the motherboard.

So I won't be doing that. I'm not that into it. Now we have a certificate change. So this is the certificate for the TPM or and this is the certificate for uh Microsoft intermediate certificate and there is a root certificate backing this up and all operating systems will offer something like this. And then a couple other things that are interesting. This is the user presence and user verification fields. And what these are saying is that I actually had to type in a PIN to verify myself to get this to create a credential rather than it did it automatically.

Right? Sometimes automatically is okay. Sometimes we prefer that it isn't. And finally, this is the public key, right? So this is the elliptic curve DSA key which will be sent to the server and stored and used to verify login later. So we're going to return these to the server and the server does a load of checks. So it checks for example that the user was verified. It checks the certificate chain. It checks the signature on this is all okay.

So a TPM did actually sign it and then it stores it in the database. So we've got the username is demo user. You'll notice that over up here when we created the credential, it it was given a random credential ID that's in B 64. It's just a binary string. The credential ID is the unique identifier for this public and private key pair and it's so that the website can say that one please later. So this is what's got stored in the database and actually you can see this right I've got my database up here and if I select uh start from users you can see it's all buried in the database right and so this PHP server can now obtain this information to verify people logging in later and that's all that's required in creating a pass key if I go into my Windows pass key settings you can see I've got my new pass key in my Windows account and you know could have many more of these if I wanted to.

Let's take a step back and and and away from that and let's look at the next step of the process. So you've created a pass key and now you come back later you type in your username and instead of logging in with a password you have the opport option to log in with a pass key. What happens? Well hold on can't tear and talk. The process is actually surprisingly similar. So we have still we have our server and we have our client.

So it all again always starts with the client. You just typed in your username, demo user or whatever on some website, right? And now the server needs to decide whether you're going to login with a password, login with a pass key. So we do a fetch of the get arguments. And these are very similar to the create arguments. They're basically saying if there's a pass key, the server will respond with what pass keys are available, what it wants to see, and the challenge token, which is really, really important.

So, this goes off to the server and makes the get arguments. And this comes back to the client. The client is going to call navigator, which I'm going to shorthand now because I fed up on writing it down. And that is going to take the JSON that was returned by the server in particular the challenge. And it's going to ask the operating system or the password manager or whoever it is that that controls the pass key to sign that thing.

Right? that's going to go back for checks with the server and then it's going to be a yes or a no, right? You logged in or you didn't log in. Okay, so let's have a look at this process. So we've already created our pass key. We can scroll down and we've got our next step which is our actual authentication. So we're going to fetch the get arguments and you can see we've got the challenge. We would prefer user verification and because we know the pass key from the database, we can provide a list of allowed credentials.

So that's saying that maybe you have more than one credential or you have more than one different device [clears throat] for that user. Like you have your phone has a pass key on it. Your password manager has a pass key on it. Right? You might have multiple in this list. In this case I just have the one and that if you recall is the ID we saw earlier. This goes to the browser which then goes to the operating system and says can you sign for me this challenge with this ID?

So we're going to run navigator.credentials.get get. And of course, what's going to happen is immediately we're going to get hopefully a popup that says, "Would you like to use this pass key to log into this website?" The fact that it's my slightly dodgy website is neither here nor there. It's Windows is perfectly happy to do this. There we go. Windows security sign in with pass key for demo user. So, I'm going to type in my password again, and we're going to get back a signed challenge that proves that I had the private key.

My device had the private key. So we still have our client data which is the origin and the original challenge and we still have the authentication data in this case which contains things like the user verification is true. Um and the sign count which is how many times this pass key has been used that can be used to check whether someone is has let's say cloned a pass key somewhere else and you actually have used it 100 times and they're trying to use it for the 10th time.

Something fishy going on. The most important thing is this signature here. This signature is the signed with the private key, client data, and authentication data. So there's no way to fake this, right? My TPM is the only thing that has the private key. It's the only thing that could have responded to that challenge, right? And so now we send that challenge back to the server and we see what happens, right? And the server checks various things, but mostly it checks the signature.

So we return a sign challenge and we verify the type of the message, which is web offend.get get the challenge is okay, the origin is okay. So, we know we're on the right website, we know we're the right username, the user was there and they were verified and the signature is okay, right? And that's it. And the status is okay. So, that is an effective login. So, unlike a password where I send a string or a hash to a server, it hashes it some more and compares that hash with the database.

It sends us that challenge. we sign it with something on our device and that goes back, right? And that proves that we kind of have a password to get in, right? But I don't need to know what the password is. I don't know what the private key is. I can't get it off the TPM. And so, um, all we know is the public key. It is a complicated system, but actually it's kind of neat, right? A lot of this data you can you don't ever see.

You just see, look, you do you want to create a pass key? Okay. Do you want to use your pass key to sign in? and um and it all works kind of smoothly. >> Look, I don't know what you've got planned for the year ahead, but if you're here watching a computer file video, then maybe it involves upping your game in computer science, coding, all that sort of stuff. And if you're serious about that, why not consider Brilliant?

It's got a huge and ever growing catalog of courses and lessons. And these are game changers. They're interactive, superbly designed, and really take you on a journey. I love the way this looks and it looks just as good on your phone as it does on a huge computer screen. You probably already know some of the basics, but this stuff can really take you to the next level. And it's also a great gift for people in your life who want to go deeper.

To learn for free on Brilliant for a full 30 days, go to brilliant.org/computerfile or scan the QR code there on screen and there are links down below. [music] Our viewers are also being offered 20% off an annual premium subscription, which gives you unlimited daily access [music] to everything.