 Thank you for the introduction. My name is Justin Mayer. I'm from Santa Monica, California. And I work on a server security monitoring tool called monitorial.com. In my limited spare time, I am the primary maintainer of a static site generator called Pelican. And I've had the honor of presenting talks here in Italy at PyCon Italia, at PyCon Japan, and various other Python conferences. This is my very first EuroPython. So I'm super, super excited to be here. And I'm excited to talk to you today about multi-factor authentication. I have found myself over the last couple of years on an unexpected journey and that has now become a personal mission to reduce the frequency and severity of data breaches caused by security vulnerabilities. And my goal is that by the end of this talk that you will have the information that you need to understand what are the problems that we have with our current authentication methods, what are the various ways that that can be improved via multi-factor authentication and the various types, and some specific projects that you can use to implement some of those solutions. But more than anything else, I want you to walk away feeling inspired, feeling inspired and really motivated to do something about this, to improve authentication security in any of the systems that you work on, any of the sites or applications that you use on a daily basis, and any of the sites and applications that your friends and family use on a daily basis. So let's begin by talking a little bit about the problem. There are an increasing number of breaches that are occurring and the severity of those breaches are becoming more severe. To mention an example that's a little close to me, Anthem is a private health insurance company that's my health insurance company where I come from. We don't have universal health care like some of you and I'm very, very jealous of that. But in any case, this private health insurance company was breached, they announced this breach in February of 2015. The average time to detect an attack is about six months. So that's six months that someone had access to my information and then could use that information to do other things, potentially get access to some of my other accounts. Obviously that's just an average, could be much longer. So what kind of information is at risk? What kind of information was potentially stolen or actually was stolen? So there's what we call personally identifiable information and that can involve birth dates, social security numbers, street addresses, email addresses, employment information, income data. There's a lot of information that's very sensitive. Anthem, this company claims that no medical data was stolen but I don't know that anyone actually believes that. There were 80 million people affected in this one breach. And when I thought about this, I realized it's not just my data. This is the data that affects my friends. My mother, she's 75 years old, she has some memory issues now and this is her information that's also been stolen. And I decided at this point that this was now personal to me because you can mess with me but you cannot mess with my family. So I decided this was something I was determined to do something about this. And this is just one attack. Last year in 2016, there were one billion records that were stolen worldwide. So it's a very significant problem. And if you're wondering whether your data has been stolen at some point, there's a useful resource that you can go to. It's called Have I Been Owned, Pwned? I don't even know how you pronounce that. .com and you can find out whether or not you've had information of yours, either a username or an email address that has appeared in some dump of stolen information. And the answer to the question of has your information been stolen and is it in one of these public available things? The answer is most likely. When I checked, there was not one but like seven different dumps or breaches. If everything from Dropbox to Adobe to LinkedIn to Tumblr. So the problem with these breaches is that there are costs. When you have a system compromise, you have the potential loss of system availability. If your system goes down, this can mean lost customers, angry customers. Data can be stolen as we've covered. You can also lose data if someone accesses your system and just wipes your entire database. And maybe you have backups but for some reason they didn't work properly. That can be a very significant impact in terms of a financial loss. In 2019, it's estimated, in case you don't feel like counting the zeros, that two trillion euro will be lost as a result of these kinds of attacks. Two years later in 2021, that number is expected to triple to six trillion euro. So why? Why does this seem to be happening with increasing frequency and increasing severity? Passwords are not the only reasons that breaches occur but I'm going to make the argument that they are not helping. The thing with passwords is they are ubiquitous. We use them everywhere. It seems to be the de facto standard authentication method that we use. Unfortunately, passwords are terrible and so we use them everywhere and at the same time they are awful and I'm going to make the case as to why that is. So why are they terrible? Usually authentication methods are evaluated using two important criteria, security and usability. Traditionally, this is involved some degree of trade-off so that improving one sacrifices the other. Hopefully someday we'll be able to fix that a bit but at the moment and in the past it has been a zero-sum game. So this is, if you have, I'm going to make the case that passwords have bad security and bad usability so it's like the worst of both worlds and when you consider this as our global standard for authentication, it's kind of amazing to think about that we've chosen this thing that has bad security and bad usability. Let's start by looking at the security side of it. The reason for the poor security of passwords, there are many but one of the most important reasons is that people choose really bad passwords, really bad passwords. You've probably seen something like this before. You maybe even have dealt with friends or family members that couldn't get into their account and when you finally got out from them what their password was, you were just dumbfounded and couldn't believe that it could be something so insecure, the most common password, one, two, three, four, five, six, this accounts for 17%, that's nearly one-fifth of all accounts, of all passwords used by human beings that are protected by this password. So why is this bad? Well it's bad for a few reasons. One, it is trivial to brute force. Any machine, your phone could brute force. A one, two, three, four, five, six password. But why would you even bother brute forcing any of these when they're so easy to guess and you can just look them up in a password list? Another issue is unprotected passwords. Even if you've chosen a secure one, people will write them on paper, have it taped to their desk, they'll send them to a friend to share an account via email or via text message. I've seen people send their passwords to themselves via email so that when they're on vacation they can use their phone to get into the site. So this happens very frequently. People will reuse passwords. Instead of using a different password for all the different things they do, they'll reuse one. So if it's compromised in one place, the attacker can use that to compromise your other accounts. And this is a really severe aspect, particularly when combined with a weak password. Another issue is phishing. If you're not familiar with what phishing is, it's one of authentication's hardest problems today. An attacker can create a form that looks like the site you're used to logging into. You can put in the logo, choose the fonts correctly, it can look exactly like Amazon or eBay or PayPal or whatever it is that you are logging into. And when you put your information in there, they just steal it and gain access to your account. This problem is only getting worse. Eric Lawrence wrote a really interesting article regarding browsers and sort of what proportion of the browser can be trusted. And he referred to it as the line of death where you have everything below this line is untrusted. But everything above that line is browser Chrome and cannot be manipulated by the site operator or whoever it is who's trying to fish your details. Unfortunately, as browsers are changing, they're modifying the way the browser Chrome appears and changing the things that theoretically can be modified. So now we're going from the line of death to zones of death. So the less and less of what we're looking at at a browser can be trusted. And it's getting even worse now with HTML5's full screen API because now you can manipulate everything on the screen. We've gone from zones of death to a wall of death. Literally nothing at this point can actually be trusted. It's just death all the way down. So we've established that, in my opinion, password security is terrible. What about usability? If you choose a very secure password, usability suffers because you're probably never going to remember it. And if you choose a memorable password, chances are it won't be very secure. So regardless as to whether you have a secure password or not, people will forget them and they forget them constantly. And as a result, we have poor security, poor usability, worst of both worlds. So why is this? Part of it is that authentication is hard. And if we had a better solution to replace passwords, theoretically we should have replaced passwords a long, long time ago. But what if inertia also plays a role? I mean, passwords have been around for centuries in sort of an offline form. We've adapted that concept for computers and we're so used to them that we don't really think of too many other ways. It's just kind of become how we handle things. So as a result, instead of replacing passwords, what we've tried to do is fix the problem. And so I'll talk a little bit about the mitigations and the ways we've tried to fix it and how they sometimes don't work. So password managers. I'm not gonna explain what a password manager is. I feel like everyone in this room is probably aware. They address some of the security problems with passwords and perhaps a lot of them. But the usability of password managers kills adoption. I feel like many of us use a password manager. We probably feel comfortable with them. But the usability of having to remember a single secure password, type in it every time just to get into something, copy and paste a password. Even if there's browser integration, people don't understand how to use the browser integration. The usability really hurts the adoption of password managers. I've set up password managers for friends and family. I've come back months later. They've never used it. So limiting failed login attempts. Sometimes, you know, like five attempts, you can, if you fail five times, you get locked out. Seems like a good idea, except when you realize that now you can lock other people out by just trying bad passwords and then now you've locked them out, they need to go through some process to get back in. Becomes a denial of service vector. This is a bad idea and basically no one does it anymore but every once in a while you see it. Changing your password often. This advice you do hear every once in a while, even in 2017, which is kind of amazing, this is bad advice. You know, it sort of follows the principle of unforeseen consequences. People then reuse the same password everywhere because then once they change it, they tend to change it, you know, across the board so that they can remember the single insecure password they're using across all of their things. Security questions. Again, probably seemed like a good idea when someone came up with it but they are terrible because they're built in passwords most of the time. Mother's maiden name. Your first pet. The street you grew up on. These are built in passwords that you can't revoke if those are the only options you're given as security questions. Obviously you can just put in gibberish, that's what I do and just put in random stuff in there but that's not what most normal people do. So as a few weeks ago, security questions got even more terrible because some password reset processes, instead of sending a link via email, they all ask you for your security questions. And so a clever attacker, a clever attacker and you really do have to admire the sinister deviousness of the person who came up with the password reset man in the middle attack is they create a registration form for something that you want. Like let's say you're trying to download a book that you don't wanna pay for and you go to some site so you can download it and they'll ask you to register. So you put in your email address, they'll ask you for security questions. They will then simultaneously take this information and pipe it into other common sites in hopes of getting access to your accounts. Again, very clever, but also very bad for anyone who uses passwords. So the industry has rallied behind this idea that because of all these problems that we have to somehow encourage users to come up with stronger passwords. And this solves one of the problems with passwords, but it doesn't even solve that problem very well because the complexity rules and strength meters, people just don't understand them, they find them confusing. And as a result, they complain. I have friends that estimate that at their large organization that over 50% of all of their support requests relate to passwords in some way or another. That's a huge percentage of support requests having to deal with this one broken authentication method. And my own experience bears that information out. The other thing is users will leave. At some point, they just get frustrated. They'll look at these rules and the strength meter and they'll just leave. And one of the reasons is that it's user hostile. You have often complexity requirements that seem totally arbitrary to inexperienced users. And oftentimes, even to experienced, technically inclined folks, these are really arbitrary rules. It drives me insane when I see someone tell me that a 10 character password that where they require mixed uppercase, lowercase, a number and a symbol, that that's okay, that that meets their requirements. But my 35 character password with whatever characters I want to put in it is rejected. One of those is a lot more secure than the other and I think you probably know which one. Users find these strength meters really confusing. They will settle for anything just to make it turn green. And so we eventually get these medium strength passwords instead of actually really good secure passwords. So assuming that you overcome all these obstacles and you actually get a secure password, you still have all of the other problems that go along with passwords that I mentioned. And most importantly, because of password resets that go to email, your system can only ever be as secure as the security of the email account that the password reset link goes to. And of course that account is protected by the user's password, which as we've established, generally not very good. So it's kind of terrible all the way down. So thankfully, there are some new approaches. Many people have tried to replace the password and nearly all of them have failed. I'm gonna talk about some that I think are promising. So some of the alternatives are gaining traction. One of them is email. When we created Monitorial, we decided to use email as the sole authentication method. We collectively, none of us liked passwords. We thought, why are we going to foist passwords on our users when we hate them? And so we decided that we were going to not have them at all. Users never have to choose a password, they never have to enter one. And the way that registration works is the same as the way log in works. You put in your email address into the field, you hit submit, a link goes to your email account, you tap on it, you are registered. When you come back to log in some other time, same process, tap, link arrives, tap logged in. You can decide, as I'll talk about, whether you want to leave that session open, just like any authentication method, you get to decide how long you want that to be left open. The links time out. So a login link, when it arrives, it's not good forever. I think ours is 15 minutes, maybe 20 minutes, but you wouldn't wanna leave a login link lying around for days or weeks or months. Email-based authentication can be used either as a single factor or in a two-factor context. We've always used it as the primary and sole single factor. In fact, it's really the only authentication method, and in my opinion, it provides decent security and usability as a single factor. I've already mentioned that username and passwords, I don't think meet that goal. And so some of the other authentication methods, as we'll see, are really only useful in a multi-factor context. So whether used as either single, sole factor, or second factor, you get good security and good usability with email-based authentication. So even without adding multi-factor authentication, email-based authentication is already an improvement over the usual username and password combination. The adoption of email-based authentication is growing, but really, really slowly. Aside from Monitorial, I think Medium, Twitter's site publishing tool, is probably the only one off the top of my head that I can mention that uses this. And I'll talk about some of the downsides. I don't know if that's why there's slow adoption or not. One is, in theory, mail delivery. So you need to be sure that these login links arrive via email and that they're not somehow routed in spam. We've never had this problem. Our login links arrive because we take very good care to set the right SPF and DKIM and all these different records. So we haven't had a problem with that, but it's at least, in theory, an issue. People are accustomed to passwords, as we've talked about. I think inertia plays a big role. And this is weird and they don't get it and they don't understand it and they just don't like it because it's different. Some experienced users don't, in theory, I've never actually heard this, but I could imagine that some experienced users might not like the latency because you tap the link, you have to wait for the email arrive. It's usually really fast when I do it. But if someone's used to hitting a shortcut key and having their browser integration, autofill, their username and password, it's mostly instantaneous and this delay of however many seconds, 20 seconds, 30 seconds, or maybe it's just switching to the email client. Maybe someone doesn't like that. Like I said, I've never heard that, but maybe. And the main problem that also affects username and passwords because of password resets is the account can only be as secure as the email account. So that part is shared with username and passwords. When most people think about two-factor authentication, they think about getting a code via a text message. Sometimes you can opt to have that arrive via a phone call. This is a very common method. Unfortunately, it's not a good method. SMS messages are often displayed on lock screens. This is a small concern, but it's at least a concern. If it's lying in a crowded place and it appears on your screen, someone else could see it. A much more severe problem is that this authentication method is tied to your phone number, which you get from your phone company, which means this method is not in your control. And attackers will use social engineering to call phone companies to have your accounts reset via email. If they've got access to your email, well, now they've bypassed the second factor altogether. They'll also use social engineering, in some cases, to have a new SIM card mailed. They'll say, oh, I lost my SIM card. No problem, we'll send you a new one. Well, now you have access to everything. Phone calls, SMS. But it even gets worse because earlier, a few months ago, it became more widely known that there's a flaw in signaling system number seven, or SS7, which is a signaling language that over 800 telecommunications companies use to interoperate. And this scales much better than social engineering. You don't have to call someone and tell them to reset an account or have them send a SIM card. You can do this in a more automated fashion. You can hit many more accounts and steal a lot more money. So this type of authentication, in my mind, in many others' minds, is deprecated. It's just a bad idea, and if someone asks for your phone number in order to set up multi-factor authentication, you already know something is wrong. So TOTP, or time-based one-time passwords, I will just refer to this as one-time passwords, or OTP from now on, just to save myself one syllable. This is based on Internet Engineering Task Force RFC, and it combines a shared secret key with a current timestamp and uses a cryptographic hash function to generate a one-time password. This is often rotated over a certain time period. Sometimes it's 60 seconds, usually it's 30 seconds. It usually also comes with a static token fallback. So if you don't have your phone, if you lose your phone and you really need to get access immediately, you can use these static tokens that are sort of one-time. You use it once and then you can't use it again to regain access to your account. This is really starting to gain momentum. And so we've seen folks, GitHub, Linode, Google, Microsoft, Amazon, Dropbox, WordPress, Facebook, Rackspace, goes on and on. So a lot of people are starting to use this, in part because everyone has a smartphone. And it does provide good security. The way that this works on a phone is you'll use something like Google Authenticator or Authy. I use a password manager called OnePassword and their iPhone app version of the password manager has support and actually their Mac version, probably their other, all their desktop versions also have support for one-time passwords. For folks that are more of the Linux free software crowd, KeyPass XC just released version 2.2 containing support for one-time passwords, which is exciting. So in terms of how it's used, this is an example of how it's done with GitHub. You sign in with your username and password and as a second step, you are prompted to put in this six-digit number in order to complete the authentication and to proceed. I think with GitHub, I don't recall what their timeout is. It feels persistent. I feel like I never am prompted to do it again unless I'm using a new device. But maybe it's just really long and I don't remember. Linode is another example and they offer a trusted agent setting that's explicit where you can check the box or not check the box. Maybe you're using a public computer and you don't want any persistence. You don't want to trust this particular browser instance. Their default is 30 days. So good security, there are some problems with it. So it is subject and vulnerable to phishing and man-in-the-middle attacks. Just like someone who creates a form to try to capture your username and password, they can do the same thing to capture your one-time password. Obviously, they need to be quick about it because the code's only used for a certain period of time. But in today's day and age, it's not too hard to automate and in theory, this could be used to get access just like if you didn't have one-time passwords. The usability is also a big problem with one-time passwords. It's just too complicated for most people. Scanning QR codes and then pulling out your phone and then looking up the entry and then finding the code and then copying the code and then pasting the code, if people aren't gonna use password managers, they're probably not gonna use this. Hardware keys. So there are various different kinds, some of which support one-time passwords as well. I'm not gonna cover most of those, including the one-time passwords because in theory, it's subject to the same phishing attack as a software-based one-time passwords. So instead, I'm gonna focus on universal second factor or U2F. U2F is a USB-based, very tiny, portable device. It is very hard for someone to get at the data that's contained within. It is supported by GitHub, Google, Dropbox, and a few others. It's slowly getting steam, much more slowly than one-time passwords, but it seems to be catching on a little bit. The way it works is there's a challenge response authentication flow. It's based on public key cryptography. And the U2F device generates a new key pair and key handle for each registration, for each of the different sites or applications that you're using. And these application-specific keys prevent tracking the user across different user accounts. So there's also a privacy benefit as well. This provides really good security. It is virtually impervious to phishing and man-in-the-middle attacks. The cryptographic handshake happens automatically behind the scenes without having to copy and paste anything. So there's a really nice usability component to it as well. And Google did a study over two years across 50,000 employees. And they concluded that this worked really well for them, that it was better than any of the other available options and they use it as far as I know across their company. So good security, good usability. It's a win-win. There are some downsides. And one of the biggest today is browser support. Only 27% of the current global population uses a browser that supports U2F. And all of that is essentially Google Chrome because there's only two browsers, Chrome and Opera, that support U2F. And like I said, 27%, it's all basically Chrome. There is a Firefox add-on. It is barely maintained. When I tested it, it wouldn't work with registering a U2F key, but if I used Chrome to register it and then tried to log in via the Firefox extension, then it would work. So that's not a viable solution. There's a, for those that use macOS, which is right about now. And as far as I know, they are not much further. So I'm hoping that by the end of the year, we'll see it. And what about Microsoft? Microsoft browser support is listed as not currently planned. So to the extent that Microsoft's browser share doesn't continue to decline into nothing, this could severely hamper adoption. There are, so what I've established is that U2F works well in a controlled environment. Of course it works well for Google. They dictate policy for employees, computers, browsers, applications, everything they do. But how well does it work outside of a controlled environment? How many people today are gonna go out and buy this little thing that costs anywhere from 10 to 15 euro and works with one browser, and it only works with one or two of the dozens or hundreds of sites that they log into every day? It just doesn't seem like a winning proposition right now today. Lots of people have smartphones. Almost no one has a U2F key. And so you can see why there's so much more support for one-time passwords than U2F keys. Some of the other issues are that desktop machines aren't really set up for this arrangement. I have an iMac on my desk, and the USB ports on an iMac are on the back. So part of the way that U2F keys work is there needs to be a minimum user input. You have to put your finger on the device. Not long, you don't even have to push a physical button. You just tap it like that. Well, if it's on the back, I can't even see it. So I'm lucky. I had a USB extension cord lying around, and I strung it in between my very weird keyboard, and so I can hit it fairly easily. How many other people have that extension cord lying around? What about mobile devices? It doesn't work on a phone to have, where am I gonna put this USB device? What if you're traveling and you've forgotten the U2F key? It's not good as a single factor, and obviously, the reason why it's not good as a single factor is someone could just walk by while you're in the bathroom, take your key, walk off. Well, now they have access to your stuff, but that's the only factor. So the physical nature of hardware keys are both a strength and a weakness. That said, for people who are in controlled environments or for people who have the knowledge and the motivation, U2F keys have the potential to provide really strong security and really great usability. I'm just gonna touch on biometric authentication briefly, really good usability, right? Put your thumb print, look at a camera to get iris or face recognition, great usability, terrible security, and the reason why the security's bad is that it's non-revocable. You cannot revoke your fingerprints, you cannot issue new ones, you cannot revoke your face. Yeah. Yes, yes, and you know, it's even worse when you use it as a single factor. You know, it's like, I have an iPhone, it's used as a single factor. If I put my thumb print on it, I get access to the phone. Yes, they periodically require me to enter my password, but just generally speaking, this is not something we should be emulating. All of these different things can be used in conjunction with like a trusted agent capability where you grant some trust to the browser instance or application for a certain period of time. So, but these different things are meant to be combined, not used independently, and that's why we have the term multi-factor authentication. I prefer that over two-factor, just because if someday I decide that this thing is super important to me and I want not only email-based authentication, but I want a hardware key and one-time passwords. I might want that someday, so I'm gonna go with multi-factor authentication. So there's no magic combination. We are still experimenting and trying to figure out what works best. So far, I'm leaning towards a recipe that begins with email-based authentication by default and only that. Again, because it provides better security by itself as a single factor than usernames and passwords. And then optionally, not mandatory, but optionally allowing the user to add universal second factor keys or one-time passwords as a second factor. I might consider adding the ability for someone to switch to username and passwords if they really were like, I don't like this method. I wanna, I choose strong passwords and I manage them well, might consider it, but if I were to do that, I would only do it if they also enabled multi-factor authentication that have to use it in conjunction with either U2F or one-time passwords. So why now? Why should we be having this conversation? Why should we be considering doing something about this now? The cost of not taking action, as I've made clear, is only getting more severe. The technologies are getting more mature and they're starting to be vetted by large companies and used in mass. So these things are starting to become more stable and trustable. Many organizations, however, still lag behind. I was, again, this is personal to me, so I started looking at my own banks. And I was, as you can imagine, not pleased with the results. Some of them offered a whole list of like five different multi-factor authentication methods. All of them were terrible. It was, you know, face recognition was one, some one-time password that was proprietary and not based on the RFC. I couldn't use my built-in app. There was all kinds of problems. One of them actually supported U2F and then required a SMS fallback, rendering the U2F support completely useless. So this situation, when I look at my own banks, it starts to get me aggravated and makes me want to do something about it. So what can we do? The first thing to do is to apply pressure to both sides, the sites you use every day, and the browser vendors. An example is domain name registrars. I use Namecheap. And so I have a lot of domains and those domains have value to me. And if someone were to gain access to those, that could cause very significant problems for me, for, you know, for my income, for a lot of things. So these are high-value targets and yet most have really terrible security. You know, Namecheap added SMS-based second factor authentication four years ago. People have been clamoring for them to add something stronger and more reliable. And for years, there's been nothing. But someone complained really loudly and very publicly a few months ago, two months ago exactly, and the CEO responded and said very publicly that he was committed to a proper one-time password-based authentication scheme in exactly two months. And that two months is today, in July 10th. So I'm very excited to, by the end of the day, to see that they will probably not have actually implemented it. On the other side of the equation, call out Mozilla, Apple, Microsoft, as the laggards that they currently are. They are lagging behind and they need to be told that. Be vocal, be insistent, and demand that they add support for U2F to their browsers. That's something that we can actually get them to do. This type of pressure does work. But it will take time. And it's not in our control, ultimately. We can be insistent, but they have to actually do something. But there is something that you can control and that's the things that you build, the things that you work on. A good first step to that is requiring multi-factor authentication for any administrative console access. So whether it's Django or whatever is here you're using to do administrative level access, require multi-factor authentication for all of those things. I understand that you can't always insist that all of your users use it. But you can usually, without too much fallout, insist that your administrators use it. And then offer that same strong multi-factor authentication to your users as an option so that if they are aware of it, if they're something that they want to improve, they can. And choose good ones. Some combination of maybe email-based authentication, U2F, or one-time passwords. So I want to talk a little bit about specific implementations. I'm gonna focus on web applications and specifically on Django. I hope that there are similar situations, I'm sorry, similar solutions available for Pyramid, Flask, Twisted, and other frameworks. But Django is the one I'm familiar with. When we built Monitorio, we used Django NoPassword. And this is a very good project. They have good docs, fairly simple to implement for new projects. Obviously a little more challenging if you're trying to retrofit it onto an existing project, but still doable, I would think. All of the different multi-factor solutions that we will talk about, by the way, will assume username and password authentication as the first factor. And so that's relevant to this discussion because when you're using email-based authentication, you're already deviating from what the other packages that offer one-time passwords or U2F multi-factor authentication, you're deviating from what they expect, and so you have to do a little bit more work. You can't use some of the built-in forms. There's another project called Django Rest Framework, passwordless, kind of long. This is a newer project in the last few months. I don't have any direct experience with it. It is designed for API authentication. So if you're more concerned with authenticating an API and you use Django Rest Framework, then this is a good project for you. I'm gonna mention Portier briefly. It's a project by Dan Callahan of Mozilla, and it's a spiritual successor to Mozilla Persona, if you remember that. It's an email-based passwordless authentication service that you can host yourself. If none of the other solutions seem like a good fit for your organization, maybe you should check this out. When I was really looking and starting to really dig into the multi-factor authentication options at the implementation level, I first started with Django OTP, and it has good documentation. It's updated regularly, and one of the issues I ran into interestingly enough is that every site I've gone to that has OTP support assumes that you will only use a single device. And this project has a little bit more foresight and assumes that you might have users who want to have multiple devices. You might have a UB key with OTP support, you might have an OTP app on your phone. This is good and bad. If you decide for whatever reason that you want to do what GitHub and Linode and others are doing and just offer one, like we just assume you're only using one, then you're gonna have to do more work because the forms they provide assume that you're gonna present them with multiple OTP devices. This project has a plugin for UB key hardware OTP support, so that's nice if that's what you're into, and it includes built-in forms for both the Django admin and for non-admin views. Again, as I mentioned before, these forms, unfortunately, they assume username and password. So if that's what you want to use as your first factor, then fine, if you want to use email-based authentication or something else, you're gonna have to do some more work. More significantly, these forms assume that multi-factor authentication is required, that you are mandating it for all of your users. And if you can do that, great. If you can do that without people complaining, fantastic. But if you want it to be an optional opt-in feature for users, you're gonna have to delve down into some lower-level APIs. Thankfully, in my experience, because, again, I didn't have access to those forms because I'm trying to apply this to email-based authentication, the low-level APIs are well-documented. I didn't have really any trouble implementing it as optional multi-factor authentication with email-based authentication. So after I experimented with one-time passwords, I really wanted to look at U2F. And because of the limited browser support and some of the other shortcomings, I was skeptical. But the code repository includes a demo project. I was really excited by that. You almost never see that. And I got really excited and like, oh, this could be up and running pretty soon. So I tried the demo project, worked really well. I thought, okay, now I'm gonna set that aside. I'm gonna use the Django admin start project command to generate a completely fresh skeleton project. And I'm gonna see what do I need to do to turn that into something where I can use multi-factor authentication and see how easy that is. So I'm gonna show you. Not as a live demo. No, we don't do live demos. So first step is to install Django U2F and its dependencies. Easy enough. U2F requires secure HTTPS connections, even for local hosts. So one of the steps to getting up and running is by generating a self-signed certificate. And that's kind of part of the process. They provide a script that you run. It kind of does that work for you, which is really nice. So I'm gonna kind of go through the different changes that I made, just so you can see how little work I did. And so everything that, all the other screenshots, you'll see after this about like the actual usage. I literally did nothing else other than these diffs that you're about to see. So added a few things to install apps. Added a couple of settings at the bottom of the settings file in URLs.py. Made a couple of changes to import the Django U2F URLs into their own namespace. Created, this is really a copy paste from what the project provided, but copy pasted a base.html template in the root templates, base.html. And really the only purpose here is to display messages if there's an error so you can actually see them. And at that point, you run Run Server Plus. I've never used Run Server Plus, presumably this is needed for the certificate support. But you run this command and we're off to the races. So again, this assumes that the standard username plus password combination is the first factor, that's why we see username and password field. Unlike Django OTP, here, multi-factor authentication is optional by default, is not mandatory. So you can tap manage U2F keys and we haven't added any keys so no keys are listed. So we tap on the add another key link. At that point, we follow the prompts and we take the key, our little physical key and we stick it into the USB slot. And at that point, there's a little indicator on the key. It actually starts illuminating and flashing. This is your signal to tap the side or top of the key. You just make contact with your skin and then immediately we see key added shown in the browser. So from the main menu, let's choose the manage backup codes option. Backup codes, as I mentioned before, are emergency codes, you use them once if you lose your device and you need to get access. So you tap the create some backup codes, it generates a list of backup codes, you copy them, paste them into your password manager or other secure vault and you have that should you ever need them. Now let's set up an OTP device. So as before, we haven't set up any OTP devices so none are displayed. If you tap the link to add one, then you see a QR code. As well as a text version of the shared secret key. I think QR codes are silly. I've never seen a good use case but if there is one, it might be this because this makes it a lot easier to get this shared key into your phone. And so the way that looks from an app interface is this is one password. This is what I use for log in. So you create a log in username, password, just like you would for any other account. If you then edit it after you've saved it, there's an option towards the bottom that says add new one-time password. You tap on that and then you see this little QR code icon and when you tap on that, then your camera is activated. As you can see here, I pointed at the screen. The recognition happens really fast and believe it or not, somehow I managed to actually get a screenshot on the first try, I don't know how, but I did, so here it is. You'll see a code scan thing on the top once it's recognized. And so now when you look at the login entry, you'll see this countdown that goes down every 30 seconds. So now that we have an OTP token, let's switch back to our web application. So we have a token, we put it in the form, we submit it, it says device added. If we tap on manage the OTP device link, we'll see that we have the device added and you can remove it, revoke it, if for somehow it gets compromised. So logging out, we see that what the log in process now looks like, it's different than before. You're still putting your username and password, but now when you get here, you can use your U2F key, you can use a one-time password, you can use your static codes, you have now three options. And I love having all these options. It reduces this lockout anxiety that someone might feel. So I'm really impressed with this project's simplicity and the first run experience. If you're creating a new Django project, consider using this to add multi-factor authentication because you get so many things kind of built in. Or try Django one-time password if you're not interested in U2F keys. Or raise some hell. Demand that your sites and your browsers support multi-factor authentication. We can do better, but only if each of us individually take some action and do what we can to improve the security of our authentication, not just for ourselves, but for the people that we care about. I'm working on a more detailed guide for implementing second-factor authentication. So reach out via any of the above methods and I'll notify you once that guide is available. And with that, we don't have any time for Q&A, but I would love to meet you. I would love to talk to you. So please come up afterward and say hello. Thank you very much for coming today.