Passkeys: Your password-free future with Ryan Hiebert

Speaker 1: All right. Thank you for coming here today. Passwords suck. You're here to hear me talk about getting rid of passwords. But before we can even start thinking about doing that, we need some history. In order to understand how to get rid of passwords, we have to understand how they got here. why we ever used them in first place and why they've stuck around even though we don't like them. I've been doing tech for A while now, and I hate passwords, and I've been looking to get rid of them as long as I've been storing them. So This is something that we keep coming up against. Why do we still have them? I'm Ryan Hebert.

Speaker 1: You can find me all over as at RyanHebert. I'm on Twitter, Fostedon, Medium, LinkedIn, GitHub. I work at Contract Safe. We make a secure vault to store, search, and manage your contracts. That's my little pitch there. Now Ah, clicker. There we go. See, identity is the key problem that passwords were invented to solve Okay, some of you got me a little bit. That's not quite right. Identification is actually pretty easy. You just need a username box. You can even make it a little simpler, remember the username, then you don't even know need that. And I guess there's nothing wrong with this if all you're trying to do is identity, but that's not really the problem we're trying to solve.

Speaker 1: No, what we really need to solve is this problem: authentication. We can't trust that people are who they say they are. So we need some way to verify it. Because if we don't, things get bad really fast. And the more important, the thing that we're doing. The worse the consequences of not solving this properly. So we introduce the password. Woo-hoo! Passwords are simple, but they aren't easy. If done right, they're very easy to use, and they're able to thwart bad actors very effectively. Uh the problem

Speaker 1: is it's very easy to not use them well. I'd like to tell you a story. My son got his first games on the Nintendo Switch recently. Uh being a good parent, I set him up with his own account. It's linked to my account so that I have to approve the purchases he makes, right? Sometimes even the stuff he wants to look at on the store. And I was amusing to him, man, I'm this is really annoying. I have to go enter my password and his thing. So I have to look it up in my password box. I don't remember it. And then type it in on this little touch screen. It's a pain in the butt. So I started complaining about how annoying it was. And he said, hey, I have a great idea for a password.

Speaker 1: Uh can you guess what his password was? That's right, it's password. See, people have a knack for creating absolutely horrible passwords. Uh and we've used a variety of techniques to help us with this issue. Uh we have complexity requirements, you've got to use weird characters or length requirements. It's gotta be so long. Uh you can look for common problem passwords like password. Or you can make sure that the password doesn't look like anything else that the user has. And there's there's other ways that you can try and make them choose a better password. But this problem is really difficult to solve. These methods aren't foolproof. They might stop the most common insecure passwords, but there's still a whole bunch of insecure passwords

Speaker 1: that we just don't have a reasonable ability to protect against. Plus, it is super annoying if you're a user and you go to make a password and then you're told that it's not good enough. That's horrible user experience. I hate that. Or let's say we finally got our users to figure out what a secure password looks like. Don't use this one. Okay. They think, all right, I have a secure password. And so they use it everywhere. Everywhere. Password reuse causes otherwise secure passwords to become horribly insecure. The sites you're putting the password into

Speaker 1: won't all keep your password safe And if you're uh storing passwords, you don't know what your users are going to be storing in your system. They might be using the same password in your system that they use for their bank account That's scary. And then it's even worse when the shared password isn't a secure password in the first place. So now we, the creators of sites that want to have users, have to protect these passwords. But wow, is it easy to implement wrong? Let's see. Uh we have to think about security at the database API application layer. We have to think about the algorithms, computational complexity, and memory capacity.

Speaker 1: We have to think about hashing and salting iterations and randomness. Point is It is easy to implement something incorrectly. Thankfully, Django does a good job of this for us, as long as we keep up to date and all of that. Okay. But if implementing passwords in your application doesn't scare you, you're not thinking about it hard enough. It's super scary. Even when it is the best choice, it's still scary. And then after all that, you still have to deal with users who are gonna forget their password anyway. So even after you do all that work to make your password secure, you still have to find ways

Speaker 1: to allow users to change their password and not just if but when they forget them. They will. Okay. So we introduced multi-factor authentication to help kind of shore up the security. And this is good. These multiple authentication mechan uh methods help us make sure that if we reset their email, maybe they have uh the device token, and we can be more confident that the reset is okay. Or it just helps in general security. So we have something you know, something you have, something you are, these three factors of multi-factor authentication. That's great.

Speaker 1: But while this is a lot of complexity, is there a better way? I have an idea. How about I make this somebody else's problem? Federation was made to do that. That's what we want to do. Alright. So here's a brief history of Federation. SAML was kind of the first one out the gate. And as you might be able to imagine, organizations, large corporations, and educational institutions, higher ed. These were the first ones to have federation because it's really important to them to control how people are getting to their systems, how they're integrated, and not letting things be open all over the place. And this works really well.

Speaker 1: This is really common today. It works very well. But this is not appropriate for direct-to-consumer applications. Consumers won't have uh an account at a university or a corporation necessarily. All right. So What are some alternatives? Well, a few years ago we got open ID, and this was so cool. It's the idea of federation. But instead of it being to a specific corporation, a specific identity provider, You federate the concept of identity providers. So you'll enter in something that looks like an email address, maybe because it is, might be Ryan at RyanHebert. com.

Speaker 1: It would see the RyanHebert. com and look do a DNS lookup and figure out who the Federation server is. And this was really cool. We had it on Stack Overflow and a few other places. I thought this was so awesome. And it just never took off. The problem is that uh the identity providers like Google Need to have a little bit more security about who they're allowing to authenticate against them because this is revealing data about the user. So now when you want to do this federation with a popular third-party service like Google, you have to register your application to Google

Speaker 1: so that they know who you are before you even get started. Alright, so then it turns into this. Continue with Google. And that's great as long as everybody has Google. But not everybody does. So maybe you Add Apple there because lots of people have that. Oh, but there's so many options. What do you choose Uh you can't choose everything. That's ridiculous. So you have to cut something out. This doesn't scale. All right. We've got to go back to the drawing board. There's a good light bulb moment that happened for me. I thought it was so cool. You see. In practice, sites tend

Speaker 1: to require email addresses. That means that instead of the form looking like this, it often looks like this. It's your email address that is your identification. Well, there's that link there. Forgot your password. And what happens if you click on it? It sends you an email that looks like this. Click here to reset your password. They're trusting at this point who you are because you're resetting your password. Well, what if we changed it to this? What if this was the way to log in? I wouldn't have to store a password anymore. I wouldn't have to store a password anymore.

Speaker 1: Okay, that sounds pretty good. And then the login box just looks like this. Just enter your email. Very good. And then logging in is the same thing as your reset password. You just go check your email and you log in. That works in a lot of cases, but it has some holes. What if you're trying to log in, but your email is on a different device? You know, you're logging into some computer. And you've got your email on your phone, you don't want to log into your email on this other computer, that would be annoying. Well, then we've got to do something a little different. We can send a login code instead, and then you have a login code that you pull up and you enter in the code. That's all right. It's uh a little annoying.

Speaker 1: The the approach seems simple enough, but hopping between the apps and especially the devices, that's a continual annoyance to our users, and it leaves them frustrated and honestly wishing they could just go back. To passwords. So we're full circle. And after all that, we've found that the compromises for our user experience just end up leaving leaving them Not with the best overall user experience. Especially when we take all this in conjunction with another major development. Password managers. I don't remember any of my passwords anymore because the

Speaker 1: password manager remembers it for me. It generates random passwords. It syncs between devices. It avoids password reuse. It auto-fills it in my browser and apps. It even takes care of two-factor in a lot of cases. So I just click on the thing and uh it'll autofill the password, submit it for me, fill in the two-factor, and I'm in. It's painless. And a lot of times this is built into our operating systems. We have Keychain , Google Chrome Sync, Firefox Sync, Microsoft, I'm sure has their version, but I don't use that. One password if you need something cross-platform and there's other options. But can we do something better? I think

Speaker 1: on this platform, from this perspective. We can look at something different, and that's pass keys. Pass keys are cryptographically secure. This is important. There's no string to write down or memorize. There's no shared secret between the server. Because there's no shared secret between the server, it's different on the client and the server, and because of the way the protocol is implemented. It is I cannot be the cause of a breach in another site because somebody reused their password on my site. My user can't log in to any other site using the credential that they created for mine.

Speaker 1: It's impossible. That's great. And it's inherently multi-factor. Virtually every implementation of pass keys available to consumers right now enforces multi-factor authentication. On my Mac, it's touch ID or face ID on my phone, or it can be a PIN code with Windows hello. But this is great. We have multi-factor and it's all in a single credential. This is widely supported, uh, approximately 90% of worldwide requests according to caniuse. com. And so what we end up with is just a login button. Or if we need

Speaker 1: Like most of us, we have existing customers who have a username and password. We can integrate it very well, and it looks just like our password manager, because it kind of is. Now there's still some drawbacks. Uh there's still some remaining challenges. You still have to recover accounts. What if they lose their pass key? Well, they won't remember it. It's in their in their vault, in their one password or their keychain. And that's still necessary. Maybe they'll lose access to it. That's a horrible experience, but you need to help your users in those cases. There are other challenges

Speaker 1: like adoption. This isn't widely used yet. We've got some good momentum going. with some major sites allowing this as a login option, but I don't know of any sites yet that have this as the premier option for logging in, where you don't need anything else. There's also issues with uh with authenticator attestation. Web auth-in was created to have very strong authentication of the devices that you use And that verification is a lot trickier when you need to synchronize the credentials between devices And so they've had to relax some things. And if you are very concerned that the devices that people are using are

Speaker 1: appropriate appropriately strong. then you may need something stronger than passkeys are able to give you right now. WebOffN can do that, but pass keys have to be a little bit more flexible. And so you kind of have to trust the user a little bit to not choose a stupidly horrible device. Thankfully, that's a pretty easy choice to make, and it's gonna be appropriate for a lot of cases. So when we compare it with password managers, I think that passkeys are a clear win. We don't have this uh shared secret that people can mess up, that they can reduce the security of themselves and their application. They're going to get a strong authentication mechanism that's very easy to do

Speaker 1: right. So, how can we get started with PASKIS in our Django project? Um use all of thank you very much. Okay, all right. But in all seriousness, if you're starting a new Django project and you expect to have real users, I highly recommend giving all off a try. Recently, Raymond Penners, the uh the primary maintainer of Olaf, has been doing a lot of work to get PASKIS integrated into Olaf. The work is still ongoing and there's still improvements to make, but I'm really happy with what I've with the progress I see happening. It's not yet possible with all authors to have passkeys

Speaker 1: as the only form of local authentication. That's my desire. But you can use pass keys in all auth right now. This is the magical uh incantation to do it. You need WebOffN two-factor enabled. You need to have passkey login enabled. You need to uh if you're doing local development, you want to allow insecure origins. Uh this is something that's being worked out in the library, but it's Keep that on there while you're doing development. And then if you want to be able to sign up using only a passkey, you need to have that setting. And if you're doing this, you probably want to have account recovery, so you need to require an email.

Speaker 1: You need to make the email mandatory. The email verification mandatory. And in order to work with how Olaf has this implemented, you also need the email verification to be by code instead of by a link, which is very common. And then if you also want to go the step further and just make email the only thing that's required, they don't need a username anymore. you can add these last two settings that do that. Alright, now we get to have a little bit of fun. This is the scary part. We're gonna have a demo. Alright.

Speaker 1: So I already have this up, and let's see. Oh, this is the wrong project. All right. So I've got this ready to go. We're gonna run the server and I'm gonna open this up in Safari. Just to prove that I didn't already just have it preloaded. I did a refresh there. You don't see my screen. Hold on. Ooh. Screen mirroring. I didn't think this through, did I?

Speaker 1: Ah, there we go. All right. Now I probably should increase the font size so I can see it too. Alright, so I got this running. This is what I just did, and you were wondering what I was doing up here. So I started the run server, it's already created, I already have a database, and I've already registered one pass key in here So we're going to switch over here. I'm going to increase the font size a little bit to make us happier. And we're just going to press this sign in with a pass key button. This theme, if you're wondering, is the example theme from the all-off uh repository. Okay, and that's all it was.

Speaker 1: I tapped on the fingerprint sensor and I'm in. I don't have a password, it's just that. If I go to this two-factor authentication, it has security keys. And I can add other security keys for different devices, different ecosystems. If I want to have one for keychain, one for one password, I can have different ones in case I need to move. Uh one challenge that we had with with hardware tokens like like this one is that I couldn't keep track of all of the places where I used it. And I was deathly afraid that I'm going to lock myself out. I'm going to lose this thing, and I'm not going to know what to do to fix it. And I can't even like go figure out all of the sites. I need to account. uh somehow record all of those sites.

Speaker 1: Because it's in a password manager, I know all of those sites. So I can uh you know be methodical and replace these pass keys. And unlike a password, when you add a new passkey, that doesn't invalidate all of the old pass keys. You can remove them. It's a different process. Because it's a device, it's not a shared secret. You're not necessarily saying the old ones are insecure now, the new one is just also being authorized. Alright, so that's what it looks like to log in. It was really easy. Man, maybe we'll do it again. Maybe something will go wrong. Let's see. Sign in with the pass key, touch ID. Oh, that was easy.

Speaker 1: All right. That is what I think is a great user experience. Okay. Well, what does it look like to register? Well, with all authors right now, it's a little bit more. But we can show you that too. We go to sign up, and there's a new sign up using a pass key. This is in the latest uh the latest uh Default uh latest commit of the default branch, but it's not released yet. So I can just say I'm gonna set up my email. It's not actually gonna send me an email because I've configured Django with the console backend, and I'll click sign

Speaker 1: up. It'll ask me for a code, which I'll get from my email. My email here again is just coming from the console. I'll paste that code in And now it's ready for me to create a pass key. So I will create one. Which is almost as easy as logging in later as well. Just fantastically easy. This is great. What if you have the pass key on your phone though, instead of in your computer, right? What if it's cross-device? There is a mechanism for it. Now I've seen some things online where people had trouble with it.

Speaker 1: I've had trouble with it. So your mileage may vary a little bit, but I think it'll work today. Let's see. I'm going to switch to to Chrome because Chrome lets me use a different authenticator to do it. Uh by default, Firefox and Safari they'll both use keychain. So that's what's been uh that's where the pass keys have been stored. And I don't want it to use keychain. I actually want it to use what I have on my phone. So we're gonna sign in with a pass key here. And it's gonna, I could use iCloud keychain or I can use my phone. And it pops up a QR code and

Speaker 1: This actually does require a bit of online, so this is a little more nerve-wracking. Let's see. Says it's connecting. I tell it which one I'm going to use. It does face ID and it logs me in. That's great. The pass key was on here, not on the computer, and it still could log me in. That is a fantastic user experience. And then of course it would be even easier if it already was on this device as well. So you can add another pass key here. The same process that we showed before. Um yeah, I think that's it.

Speaker 1: So let's get back to it. Yeah. All right, back to the demo. All right, we'll finish that. Oh, there was one other thing. Maybe you've created a user and you need to figure out how to make them. staff or super user and the the method I use for that is to use the shell it works pretty well I'm working on it thank you Mirror.

Speaker 1: So if I open up a new shell, uh terminal If you don't use Django extensions, which gives you this shell plus command, I encourage it. is a great shortcut because it imports all of your models very quickly. That's great. So So I've got that user, and I'll set is staff true and His super user true and then save it.

Speaker 1: And now when I'm logged in with that user, which is this one, I can now go to the admin and it'll let me in. Great. All right, thus endeth the demo. For real. Thank you very much. These are some resources for you. These are really good resources: webauth n. guide, webauthend. io. They they talk about the details of how WebAuth

Speaker 1: N is implemented in the JavaScript API and the protocols. It is and they're really, really slick. Caniuse uh com, paskies. dev. Of course the docs for all auth. And if you're interested, this um this last link is about uh a maintainer of uh a web authend package who's actually kind of bummed about where pass keys have have gone and he's not so bullish on it anymore. I think that pass keys have a real possibility and I'm excited to see how it goes. Thank you.

Speaker 2: Thank you for for the talk. What if your laptop or your PC is very old and don't have any touchdown? uh control uh fingerprint or you are working with Linux or you are in different position

Speaker 1: What if your laptop doesn't support pass keys?

Speaker 2: What if you don't have a physically the the

Speaker 1: uh a scanner

Speaker 2: It's kind of a for if you are or sure.

Speaker 1: So uh some computers that I've worked with don't have the the biometric scanner, and so they'll use a pin code. Uh that's pretty common. And so you have something you know it's it's a password, um, but it's locally stored. And so the authenticator is still uh The site does not know that passcode and it's stored locally, plus you inherently have the device also as a second factor. You're using a device and you're authenticating. um in some way, either with a biometric or with a pin code. And so that that works pretty well.

Speaker 3: Can you talk a little bit about like not the cryptographic details, but like what's generally happening under the hood? Like what are you storing in the database in in Django and what is the client sending? Uh at a at a very high level like how is this working?

Speaker 1: There are a few details in there. The server has an identifier. The client the the authenticator client also has its own Well it's gonna it's gonna generate a key. Um those are uh

Speaker 3: It's I I don't I didn't mean to stump you on this idea.

Speaker 1: You're not stumping me. My mind is going blank. This is this is a speaker moment. I appreciate that. Thank you. When when it uh when the server wants to send it, it will send its ID. The client will also check the domain. And it uses those together to make sure that the credential it creates is only for that. So it will generate this credential, which is a secret and an identifier, and it stores one half of this uh cryptographically secure secret locally and never goes to the server. The other side goes to goes to the server. Together they make the secret work. And then there's an identifier that the server stores

Speaker 1: so that the next time you come back it says, hey, I know about these identifiers And so you can you the the client can look up, hey, which ones are appropriate, which uh which accounts do I have here, which pass keys do I have for this site? And then the uh the server itself can actually say, no, I want you to tell me whether you have this specific credential and verify that as well. Which um and then there's some additional functionality for making sure that the the display name stays up to date, because what if you change your username or your email address? As you can imagine, this all takes work to implement and not every server is going to implement this correctly, but these provisions are there in the specification.

Speaker 1: And then other provisions for the server deletes it. Well, how does the client ever know that it's gone and it needs to be removed from their system? Because it might pop up and say, hey. I've got this pass key credential for the server, but the server doesn't know about it. It's not valid on the server anymore. So there's provision for the server to say, hey, I have these, I have only these pass keys for this user. And if you see anything else, that's not uh it's not going to work anymore. Hopefully that's a better answer than my bumbling around at the beginning there. Yeah.

Speaker 4: Hi. I'm curious how you feel about such a core battery authentication relying on third-party packages long-term. So I guess how do you evaluate the pros and cons of Something like this being third party versus eventually in core.

Speaker 1: Oh, I would love to see this in core. As I've learned more and more about authentication, various methods, the reason I recommend ALOF so strongly. is because it turns out authentication is really, really complicated. What I need at my site, it seems like the obvious thing. But if I go to a different site or a different company, they need something different in ways that I would never have imagined. And I found that over and over again. So Olaf is a very complex package that manages this pretty darn well. And I'm really impressed with it. That being said, there is room for us to have a simple implementation of this in Django Core, and I would love to see that happen

Speaker 1: I think it probably needs a little bit more proving out in the third party space, as much as I hate to say that. I really want to get it in there, but we want to make sure that we understand it well enough before we pull it in and make everybody use our design of how passkeys should work.

Speaker 5: As a user, what steps or practices should I take to use pass keys correctly? Like right now I see them all over the place. Every time it says you want a pass key, I say, sure. So I have one on my desktop where I swear I just click OK. I don't even have to Authenticate. I have it on my laptop where I fingerprint. Sometimes I make it push to my phone. Half the time it doesn't work when I push it to my phone. PlayStation Network is a hot mess. They are like, do a pass key, it's awesome. And you set it up and it fails and it never works. And you turn it off and reset it and you do that for an hour and you give up and you keep your password. To recap, what should I be doing as a user to use past keys

Speaker 5: more correctly

Speaker 1: Uh I think these rough edges that you're experiencing are ones that we need to be aware of. And uh I don't I don't really do PlayStation, so that's not an experience I've had. But there are some things that you can make thing that you can do to make things better for you. I think the biggest one is understand where you're storing your passkeys. I use one password for everything, so I know it's there. And I have gone through a little bit of trouble to make sure that I'm not using keychain on some other devices that might mess things up. It took me a little bit of work here because I had to switch things over so that I was using keychain here so that I could demo the uh the mobile authentication for you. So that's probably the biggest thing. But I

Speaker 1: think there's going to be some challenges as companies, as devices figure out how to get pass keys working right. We're still in the early stages where where people are are getting it in there but messing it up. And we have to get through those those rough edges. And um I think we can go a long way right now for a lot of users for simple projects because it's built into iOS, because it's built in to Android. And so some of some common use cases may not need a password at all, you can just do that. But most of our applications are still going to need other forms of authentication. We can't get passwords yet until we have more adoption from users and users understand them better.

Speaker 4: All right, another question. This one's from online. Hi, Ryan. Great talk.

Speaker 1: Thank you.

Speaker 4: This one's from Adrian. I have a question. How would you handle a user who needs two separate user profiles on the site? Right now I could use two different emails and two different passwords. Would you just have to choose two separate pass keys somehow, one for each profile?

Speaker 1: Yes. So each pass key that you create is going to be associated with a particular user profile. That's really important. There's a user identifier and there's also the display name for the user so that and that's what's displayed in your password manager. But I can have multiple accounts on the same site. There's no restriction against that. And I think that's actually really important, a really important use case. Did I answer all of the question? What was the other half? I think you get heard. Oh, okay. Uh

Speaker 6: was that everything for your question? For the online question?

Speaker 1: All right, great.

Speaker 6: Uh because I like to make myself unhappy, I just did a search for pass keys and patents and it found some things. Do you have any idea if there's any patent issues?

Speaker 1: I have no idea.

Speaker 6: Excellent. We'll say no. There are none. We can live in a happy place.

Speaker 1: Um I I know that it's implemented by major companies, so either they've figured it out or they're gonna get in trouble. Um I guess uh I'm less worried about them.

Speaker 3: So this Both as a site maintainer and also as a user, how should we think about pass keys with regards to two-factor authentication? Um, because on the one hand, pass keys do have that device ownership restriction built in, but on the other hand, there is still a single credential that could theoretically become compromised. So are they a substitute for or should still actually be used in conjunction with two-factor authentication?

Speaker 1: That is a very good question. And I think it speaks to the complexity that I was talking about. There are multiple factors, we have two-factor, but there's also another complexity of multiple credentials. And historically what we've done is we've said multi-factor authentication means multiple credentials. We're going to have our password, that's our first factor. And then we're going to have our device token, our our uh Google Authenticator that will be our second factor. But those aren't just factors of authentication, their mechanisms of authentication. Or you have email that is kind of a form of federation. You

Speaker 1: you go to your email to log in there and it's all depending on how much you trust the uh authentication of the email provider in the first place. So we're kind of federating out that responsibility again. You really have to understand what your security requirements are. A lot of times uh I'm I'm most interested in the little side projects that I'm hacking together. And security isn't the highest priority. I want to do it right because that's really important to me. But I don't want to make things over complex. And so maybe what I'm going to focus on is just having passkeys. The email authentication is good enough for doing the reset flow, but it's not a good enough user experience for logging in.

Speaker 1: So pass keys are that optimal experience, and then I have a fallback to email. But other times, you can't trust the email. That's not sufficient. And so you can use a hardware token that is able to have stronger device attestation. And you can use that as a second uh authentication mechanism, a second credential. And that one can have stronger impact. And and that kind of feels like the way we've done multi-factor authentication. And you can still say, all right, uh if you have a second credential that's a hardware device, And it's not a pass key, then you can use that to verify as a second layer in addition to your email, and then you can validate it.

Speaker 1: And so that might be a way to allow recovery and keep a stronger security. Or you might need stuff that's even stronger where you need strong attestation and a passkey isn't appropriate at all Um or not as uh the only authentication layer, and you need to use uh a device where You can enter the username, and that's enough. And the device itself has strong attestation and can send back the credentials once that username is inputted. The brilliance of passkeys is that I don't even have to type in the username. I don't have to remember that username. It's in my password manager for me. So it makes that user experience seamless and easy and refreshing.

Speaker 7: All right, we're right at time. So thank you so much, Ryan. We appreciate your talk. It was wonderful. Give it a round of applause.