Bringing modern authentication to Wagtail: WebAuthn and Passkeys

This we'll have to do. Um , that's my cursor It's down here. All right. Hello folks. Um, nice to be here. I'm Storm Heck. And I'm an independent contractor from the Netherlands. I work on uh Wagtail and Django applications. I'm also a member of the Recto Core team since 2021 or so. So for a couple of years. The accessibility team I'm also a member of. And currently I'm also the lead mentor for a Google Summer of Code project. And we're working on bringing extended

alt text capabilities to Wagtail, but that's not what I'm here for today. Today I want to talk about traditional authentication as we know it, passwords, multi-factor authentication, and I want to Tell you why you shouldn't be content with that. There is a better alternative that you can use. That's what the next part is about. Introducing pass keys. And what makes them a better alternative? And at the end I'll go to show you a quick demo of a package I created to make this easy to integrate into your rectal site. But first, passwords. Raise your hand if you are using a password manager. Can I see some hands?

Yeah, this is what I expected. We are a developer audience. We care about security. Good for you. But not every internet user is as security conscious as you are. And here are a couple of pain points that I know exist for passwords. There comes something and that's why people tend to choose easily guessable passwords. And this all passwords also have the uh they are a shared secret, they can be uh uh stolen. either through like uh fishing, a user goes to a phishing site and enters their password there and suddenly there is a leak in your uh application

Or maybe they have uh acquired malware on their uh computer that is logging all their keystrokes and logging passwords. Um And because passwords are often reused across sites, uh this leads to an attack called credential stuffing where if uh a credential or a password was previously uh uh leaked then an attacker can try hey does this credential match with any other uh user accounts on other websites so Even if your security is uh strong, well because of someone else's uh uh website leak and your user reusing their password You're still uh uh you're uh can still be hacked.

Uh password managers they help in this regard, but they are not universally used. I don't think most non-technical people use a password manager or even know what it is. So let's get to my daily annoyance. I'm security conscious, I also use two-factor authentication, and this means I have to enter them. And I have to go to an app on my phone and I have to look up this uh at this uh six digit code and I have to transcribe it onto my uh computer screen as quickly as possible. because in a few seconds it's going to expire and oh I'm too late. I have to re-enter the code. I have to do this daily. I'm really annoyed by it and that's why I'm giving this talk.

Why I want to make it better. Um let's talk for a minute about uh the common uh second factor implementations uh we see out there. We have the time-based one-time passwords that I think are most common. These are the expiring codes I just told you about. But we also know uh SMS verification codes is appears also to be common. But has this ever happened to you? You switched phone numbers and now you can't receive the SMS code you need to log in because you have a new phone number. Next, uh codes delivered by email. I every time I have to log into my uh GitLab account, I get an email with the codes.

and I have to wait for the email to arrive and then I have to copy the code, go back to the window with GitLab in it, and yeah, it just takes precious time. And yeah, I want to be as productive as possible uh during my day. Yeah, and also somewhat less common, but uh uh uh it's still uh out there. It's uh Tap to approve. It's by far the easiest way to log in, you get like uh a notification or a pop-up on your phone like, hey, is this you? Do you want to approve this? But perhaps this is also the most insecure because you can accidentally approve these prompts And sometimes it happens that a user or an attacker is

attacking an account and a user is spammed with a lot of uh uh approval requests and yet they uh user isn't physically present so they can just tap approve and then somewhere somewhere there is an attacker uh logging into the user's uh account Can't we do better than this? Isn't there anything else or are we lost? This is where uh web outn uh comes in It's a pretty new standard. It's been around for a couple years now, but it's recently gaining traction with uh large tech businesses like uh Google. and Apple like they are really ding into this and they are making uh integrating web

out and into uh their uh platforms like iPhones and MacBooks And what Web Out and does, I don't think it is necessarily the a silver bullet to security, but it is A very nice way to make this better a better user experience. So, how does this work? It's based on uh public key cryptography, so there is no shared secret uh like a password. Um A user they uh register a credential with your websites and this is where uh pass keys come in. Uh there is like a very it isn't a an

exact definition of pass key, but it's more of like an umbrella term for this uh standard. But for the purpose of this talk, I'm going to define it as The credential that is registered on the website and that is being used to authenticate. So this is the uh the public key pair that is uh uh created. Um so uh when a user registers uh a pass key Um a public key pair is cre or a public private key pair is created. The private key is stored on the user's uh device uh securely and we as the website implementing pass keys. We get the public key and we store that on our site along with a reference to which

which user this this is And whenever the user wants to use their passkey to log in, we, the server, the website, we're going to send a challenge. to the browser that is currently trying to, or the user that is currently trying to to log in. And we're going to ask them like, hey, sign this challenge with the private key you have. And this signature is sent back to us. And we use the public key we have stored for this user uh to check that signature. Is this actually a valid signature? If it is, then the user or the person on the other end must be in possession of the private key and it must be

who they say they are Um there is an additional uh step to this because uh devices they aren't going to um make the secret key available for signing immediately. They're going to perform like an additional uh verification like maybe uh the user left their their laptop unlocked and someone walks along and they try to to log in. Well That's where why the devices they perform additional verification. But you can use your computer password, or if you have a laptop with a fingerprint scan, you can use a fingerprint scan. If you have an iPhone with face ID you can uh do facial uh recognition. And this is not something that we have to worry about.

It is This is implemented by Google and by Apple on their hardware, their software. And I think it makes for a really nice uh integrated experience. So, yeah, the benefits. Like I mentioned, uh no shared secrets. Uh I think that's a benefit. By design the keyper is created per site, so pass keys are unique. So if the secret key were ever to leak then it can only be used to log in to the website it was created for It's not like with passwords that are reused across websites. So yeah, the blast radius

is is is less with that. Um they are bound to a specific domain too, so fishing uh attacks they are ineffective. Um You can't use a pass key to authenticate on a domain it wasn't registered for, like the your web browser just won't give you the option to use this uh pass key. This does have like a slight uh disadvantage to it because Wagtail is a multi-site and usually uh users or editors. Can access the admin through like the multiple uh domains that are connected to your Wactor instance. Um well the pa Apaski isn't going to work, it's only going to work on the domain it was registered for.

Um if you have another domain like uh a different uh uh domain then you you can't use uh this pass key. So For now, a user would have to register like multiple passkeys, one for each domain they want to log in from, or just access the admin from the same domain always. Um so let's have a look look at how registering a pass key how that works exactly. I just explained it very briefly and it's like magic, but how do how does it work uh exactly So we begin uh at the top with uh this is always initiated by the uh web browser. The web browser has uh an API that we

We can call from JavaScript to begin the passkey authentication process. But before we do that, we request from the server uh a couple of options like maybe we uh uh e uh expect like uh specific uh security uh uh options and we also have to defetch the challenge we uh need to sign Um and we uh we get uh back the options and the challenge from the server. And um At that point , the web browser is going to show a pop-up, usually a system uh pop-up, like hey uh what pass

key do you want to use? uh to log into the site and it can list the pass keys uh that are already stored on the device. Um And the user can select one and then it creates the uh the uh signature and uh we send that back. uh the public key or sorry the um sorry the yeah the registry uh sorry I'm talking about registration I was um When we register, uh we're going to send the uh the public key that was created along with the uh credential ID. This is also created by the web browser and it's just a very large opaque uh string of uh of bytes

that is uh uh unique but every time we're going to use this pass key uh we get this credential ID so we can use this to look up the the public key we have in our database. And yeah, that's it. Then we have registered a pass key on our website. And after the initial registration, uh what does the authentication process look like exactly Well uh once again it's initiated by the client by uh JavaScript calling uh a browser API And again

we uh ask the server for uh uh some options and the challenge that needs to be uh signed The browser is going to show a system pop-up again, like hey, which pass key uh do you want to uh to use And it it sends the credential ID and the sign challenge. And on our server we look up like, hey, do we have a pass key stored with this credential ID? Take the public key for that and use that to verify the signature. And if it matches, okay, then log in the user we know is associated with this pass key. Well, this all sounds pretty complicated, right? Uh there's a lot of interactioning uh interaction happening between the user, the device, browser APIs, your backends, uh you have to store our uh data on your backend, you have to do like

Cryptography, verifying signatures, all complicated. And you're right, it's a pretty complicated standard, but the hard work is already done for you. Introducing uh Ractil MFA. It's uh a package I've been working on for the past couple of months. It's uh not feature complete yet. Some important features are missing because I uh want to add uh the traditional uh uh uh multi-factor authentication uh uh too like these uh time-based uh codes just for the devices that don't have don't have uh uh pass keys yet there needs to be uh a fallback And right now, since yesterday, I'm officially

past the proof of concept stage. It's just adding more a little bit more features now. Documentation tests tests are completely lacking right now uh and some more uh uh polishing. So uh let's check it out. Let's uh Go to the rectil admin, register a pass key and use it to log in back or to use it use it to log in to a rectil admin without using a password at all. Completely passwordless. Um so let's have a look if I can show my uh Safari screen

Just appear. Here we go. Oh this is difficult. Uh let me just mirror my screen quickly. Uh which option is it?

So here we are in the bakery demo. Um so let's go to our account and go to more actions, manage authentication settings. And here it is, the custom fuse added by my package. We don't have any pass keys registered yet, so uh let's get started. And uh register one. So here we get a pop-up from uh uh from uh uh Safari from macOS like hey do you want to use uh Touch CD from my MacBook? uh to log in and a pass key will be saved to my uh iCloud keychain. Yeah sure let's do that All right, it's created.

Let's give it a name. Call it my MacBook And there it is. Well, let's try it. Let's log out of the admin and look what we have here. Uh Safari knows it has a pass key for uh this website, so it already uh prompts us, hey, do we want to use this pass key? Yeah, sure we do. And again, just with a touch of my finger, here I am locked into the wagtail.

So what do you have to do to add this Rectil MFA to uh uh to your rectil project? Well, you have to install it from pip and afterwards uh you have to add it to your uh installed app setting. And um you have to set uh a couple of uh uh additional settings. One is the uh uh uh RP ID, the relying party ID, and this is the domain that your uh that a PASCE will be bound to when it is uh created. So this should be the primary domain of your uh uh uh your back to the site. Uh and we also set the RP

name because uh some authenticators, some browsers, they in the pop-up they show when you want to create a pass key. uh the you can add your own uh uh business name here like hey do you want to create a passkey for uh my company incorporated And one other important thing to set is the uh allow allowed origins. I see I made a typo in the setting uh name, but uh you didn't notice And this is a list of uh origins that uh pass keys uh can be uh used from. And it's very very similar to the uh Django

uh cross-site request forgery uh uh origins uh setting. It has a security uh purpose And the only other thing you need to uh to do I think this is uh the wrong the wrong image in my uh slide the same image again but there was supposed to be an image here of uh adding uh the wagtail mf a urls to your url config And yeah, that's it. That's all you have to do. And this is a default implementation that I think works very well. uh for most if you don't uh want to spend a lot of time uh integrating uh passkeys. Uh but it's based on another package I wrote which is more for uh Django

and integrates with the the Django OTP framework. for uh managing uh um uh fac verification. Um and yeah Even outside of Ractil, you can integrate pass keys in your Django application using the lower level Django OTP Webout N library. Yeah, thank you. Here it is.