 So, I'm a native San Franciscan. I've lived and worked also for many years in the North Bay, in fact, just a few miles from here. So, it's really a special kind of privilege to get to be here at the podium for the very first North Bay Python conference. And I have to admit I lobbied a little bit. I speak a lot at conferences, a lot of different countries around the world. It's pretty cool. And they're each a different kind of exciting, but my favorites by far are the ones that are small and regional and single track and doing everything possible to bring newcomers into their orbit. Grassroots is heck. And especially that just are unabashedly in love with their location. So, does this sound like anyone you know? Yes, North Bay Python is full of these. I am just a straight-up two-factor-auth enthusiast. I study it voraciously. I don't do application security for a living. I'm also not a cryptographer. And you don't have to be either to appreciate this talk, okay? Crypto is not what this talk is going to be about. It is about something else entirely. This talk is about a particular kind of perspective and what it tells us about how to empower other people. And that's an unabashed love letter, too, because what I hope to do is instill a love of two-factor state of mind in you. And I'm hoping that you'll pass it forward, too. Our industry likes to envision change in the world. Two-factor-auth offers us genuine opportunities to impact the lives of people who are vulnerable. So, that's why my mission is to make you an enthusiast, because regardless of whether you have program experience, there is plenty of stuff that we each can do. So, are you ready to get started? Come, say it. Say it for real. We're recording audio here. You got to put it on record. All right, so let's start with just breaking down some terms, including just the name itself, literally. So, what is a factor? A factor is something that supports an individual's claim of identity. And specifically, there are three kinds of factors. Something you know, something you have, something you are. So, in other words, knowledge, possessions, or something inherent to you. There are some common examples here of possessions which are a tangible thing versus knowledge about what would be on that thing or in that thing. So, for instance, banking, phones, birth records, residences or purchases, standard kind of stuff that we deal with every day. And that's what I want you to think about, is that we deal with two-factor auth every day, regardless of whether there's a computer ever in our presence. And that means as well that lots of people other than us are using two-factor auth all day long and don't know it and have the power to understand these concepts once we're able to analogize it to stuff that they're already doing. Here's some more examples, adding in, of course, inheritance. So, obviously, things like passwords and passphrases are things we know, mostly-ish. Pins, our phone number, other people's phone numbers occasionally. Some sort of government ID, like a driver's license or a passport. Of course, the lovely traditional mother's maiden name. So, possessions, these are ones actually we use pretty often. Things like key. I assume that you have some sort of keys. Something like an employee security badge. A key fob. Using something like RFID to identify the key. Hard tokens, which we'll get to later. Smart card, like, say your transit pass if you're in a city that does swiping instead of cash. Passports, utility bills to verify that your address is what you claim it is. And then we get to the inherent stuff. And this is essentially, but not entirely, biometrics. So, things like fingerprints, hand prints, facial recognition, facial identification, which is a subset of that. The difference between that is a face and that is her face. Voice prints. Things like Apple's, I'm sorry, Alexa actually, Alexa Home. Amazon Home, Alexa is recently added voice identification. So, this stuff is already in use as you know. Things like facial identification are being used right now by iPhones. We also have stuff in some corporate use and also in things like border security, using iris recognition, retina recognition, and that gets to really interesting things. Did you know your typing cadence uniquely identifies you or at least knows it down considerably? Just the sort of rate at which you hit different keys, it takes only a couple of sentences to pin you down. Which is so creepy. And lots of other behavioral patterns like that. If you think about things like if you have location on and your phone turned on, the fact that you spend a fair amount of time at a predictable hour, a sequence of hours every day at the same place, or going back and forth between two predictive places tells a lot about you and suggests who you may uniquely be if you can pinpoint who lives at that address and who works at that address. So together that behavioral pattern is identifying you. So we have all these different ways and they're very different. So this is an important point. Authentication and authorization are really easy to trip off on, even on saying them for instance now. So it's really important to clarify. Authentication is about establishing identity. Whereas authorization usually is after that saying, for instance, let's say there's a guard at a military base. They got the barbed wire in the one place to enter. You have to first prove that you are perhaps a military officer or someone else who is potentially authorized to be there. Having proven who you are, then the next step is to check, is this person authorized to actually enter? You are who you say you are, but that doesn't necessarily mean you have the right to go in. So that's the distinction that's important to make. I will not be really talking about authorization at all. So other than this distinguishing, you could just throw it out right now. So let's look at the process here. So first there's interstitiation. I am someone who's authorized to access Super AmazePants resource. And then you get from the server challenge, well, prove that you're that person. Well, here's my evidence I present to you. So now we have challenge and response happening. And then there's a checking out, okay, you convinced me that both of these together are showing who you are with just that one form of ID. So at that point, authentication has been established. The next step is, like I said, that authorization. Okay, now that I've proven who I am, let me actually go to Super AmazePants resource. Checking the list, okay, you seem to have the authority to do so. Two-factor authentication is when you combine any of those three types of factors with a different type of factor. So you could think about this kind of, like, the lunch special in a Chinese restaurant where you've got the various, like, pick some sort of super salad, plus an entree, plus a couple of things, like, you know, rice or tempura or whatever, right? So you've got these different categories, and you could choose one of this and one of that. In fact, you have to choose one of this and one of that. So essentially what you're trying to build here is resilient security where, even if the first factor is compromised, an adversary is left with work to do. The second factor is still standing, and the very fact of its difference should be requiring the adversary to change their strategy. The underlying premise of Two-Factor Auth is that each of the factor types has differing strengths and vulnerabilities, none is inherently better than the other, but because of the differences, they're able to shore up each other. So when done right, Two-Factor Auth is reducing false positives in identifying. But of course, it can never eliminate false positives entirely because things like knowledge can be found out, right? It can be researched or overheard or tell someone. Possessions can be taken or borrowed. Physical properties of yourself can be reproduced. Or you may have a twin. So all these things, let's look at this from a different perspective. Again, going to the everyday. Okay, so a combination lock would be a knowledge factor because you have to know the combination to open it. And the point of that is to prevent opening some sort of container of objects or maybe it's containing information. There's some sort of thing that we're trying to protect inside. And then handcuffs are a possession factor. And that means that the attacker is going to have to be in person. And the point of using handcuffs is to restrict movement of hands and arms. So they're both locks, and they're doing extremely different purposes. Whereas two-factor auth is about layering. And take a moment to think about, say, what a courier of secret documents or maybe diplomatic documents is doing, where they have a locked container and handcuffs, but they're being layered together to very different effect. So now that combination lock is protecting against the courier themselves, keeping them from opening up, looking inside, since they do have physical access. It's also keeping them from accidentally losing it along the way or having it conveniently grabbed, you know, like a smash and grab. So we've got this effect of each adding something to each other. Two-factor auth.org is a great site. It maintains a long list of apps that support two-factor auth, as well as apps that don't. There's a GitHub repo, so feel free to contribute to it. Because this page illustrates several different categories, we're going to delve into those in more detail. One thing to notice, it's normalizing two-factor auth as a normal state and the lack of two-factor auth as an outlier state. This is the first principle that we can think about two-factor-mind. Take any small action that normalizes two-factor auth in the eyes of others. This is something that we can do. Notice also how it's making it really easy to make that kind of difference, just by tweeting, you know, just by putting a little something on Facebook. They're even letting you just click to do that, making it as easy as possible to make some kind of difference. It may seem trivial, but I mean collectively, some of these sites really only need to hear from a few people complaining, why haven't you done this? Or even just educating them, did you know that you could be doing this? It really can have effect very easily. So do a thing, anything that makes it easier for others to move forward. And that might be alerting, it might be asking, it might be pushing. And yes, some approaches are more resistant to specific types of attacks, but it's really important to keep in mind that, for instance, if someone doesn't have a smartphone, maybe they can't afford a smartphone, then some of these strong approaches are 0% strong for that person. So each time we're weighing these things, they're not objectively better or worse, they're contextually better or worse. And that's why it's important to treat all approaches as legitimate. Don't make the decision that the only method is the one that is cryptographically strongest, because that's still not necessarily the attack that they need to be worried about, or that meets their needs of balancing, for instance, security versus convenience. If something's too hard to do, they're gonna end up doing an end run, finding some way to disable it or walking away altogether. So treat all reasonable, legitimate approaches, regardless of your opinion of them, as at least legitimate to discuss in a way. Present those options without any value judgment. It's really helpful to be able to open a conversation and ask questions, rather than say, this is great, this is what you should do, this will really help. It may be, but... For example, budget is a significant constraint. And that's for businesses, that's for individuals. If you have to buy a whole bunch of licenses, then even an enterprise is gonna be considering, you know, what are the training costs of this, the support costs of this, maybe we don't wanna go there, we're already on an internet, so we feel like we already have a fair amount of wall built around our communications. For an individual, it may be that $15 is just really out of their range for something that they don't envision as protecting from an attack that they can imagine whatever happened to them. So help users identify a realistic sense of what threats could be pointed towards them and help them think about constraints so that they can begin to weigh different options for how these fit in with their needs. Best is never a universal. Best is whatever methods best balance their security needs, their budgetary constraints, and their convenience. So as I said, we've got this list. And it's broken down into a few categories here. Let's look at these each. So those categories that are titled SMS, phone call, and email, they're all typically referring to one-time passwords. A one-time password is a password that can only be used one time. So as soon as it's triggered, it's dead. You cannot reuse it. And the value of that is, as long as you, the valid user is the one who's used it, you've precluded anyone else who, for instance, looks over your shoulder from using it as well. A backup code is an example of an OTP. It's just a static password of some kind. It's provided in advance, usually for safekeeping, so that if there is some sort of disaster and you can't get in any other way, you've still got this backend that you can use in the future. So you've probably gotten something like this. Here's a list of passwords. Stash them away. Time-based OTPs are a little bit different because they're dynamically generated on demand using a shared secret key. We're just talking about public key encryption here, and a current timestamp. And those should be invalidated after a certain amount of time. That's the whole point of using that timestamp. And the time-out is really giving way to the user's timetable. So if it's something that they can get to immediately, you can have a very short time-out window of a couple of seconds or a couple of minutes, depending on what it is. Other options, you need to give them time for things like communication systems may have some delays in them, or they may need to go log into some sort of account themselves in order to get that password for this other account. So we need to adjust what the time-out is, depending on the technology. So SMS is referring to TOTP via SMS. That's getting generated by the server-side app and then texted to the user's phone number. The fact that it is that person's phone number is considered to be then a possession factor. Something was sent to them, and supposedly the only person who should be able to access that, then, is the correct authentic person. So with something like that, the expiration time-out is typically set somewhere in the range of five to 15 minutes. It's really up to the individual app to decide what they consider a reasonable amount of time. So for instance, you get a text saying something like, yourexample.com login code is blah, blah, blah. So that's what that SMS column is referring to. TOTP via phone. This is just generating a call at server-side, generating the code, and then dictating it over voice to the user. And this is even if you feel like some other factor is the most appropriate for most people. Keep in mind that still use this, still include this in your implementation, because at minimum, there are users who don't have mobile phone service. I know, it's shocking. They really do exist in significant numbers. So that's why we have to make sure that those people aren't being left behind. And sometimes you have things like, for instance, you go out of range of mobile service. Maybe you can't get data or SMS, but you can manage to get voice. So even when you don't have... When you assume that you're going to have mobile access, from time to time, you find you don't. So that brings us to another principle of two factor mind. Be mindful that each two-factor-off method has some kind of accessibility issue. And that means it's up to us to leave no prospective user behind. And if someone's app has done this, someone else's, please point out that problem and suggest a solution to it. All right, so as I mentioned, time-outs vary. By the way, with something like e-mail, you usually want to give it a fairly significant amount of time. Make the assumption that they probably got two-factor-off, or really, really should, on their e-mail account. The reason being, you have every single login in some way connected back to two-factor-off, right? Every time you hit forgot my password, what does it do? It sends a code or a reset to your e-mail account. So if you do nothing else, have two-factor-off on your e-mail account. But that does mean that now, just to log into some other account, you're going to need to take a few minutes to log in via two-factor-off to that e-mail account. So that's why we want to have a little room. And so this is what the e-mail column was referring to. So now we have TOTP Software Token and TOTP Authentication App, and they pair. So there's a shared cryptographic secret, and that's being used to calculate a six- to eight-digit TOTP. And the default expiration for this, this is written in the spec, is 30 seconds. This is something you should be able to generate immediately while holding it in your hand, and you're meant to copy-paste very quickly. However, there is supposed to be some wiggle room. Not all apps actually respect this, but there should be a buffer of 15 seconds on either side of that. So even though the app is showing this, you know, 29, 30, it's expired, it should be still usable for 15 more seconds, whether it is or not, is really up to the app. On both sides, I should say. So the nice thing about this is you can have a separate token for every login account, even if you have multiple ones on the same server. The spec is designed to cope with this. And so you can see over here we have an example token. Usually you just scan in the QR code, you can, if you need also, just manually enter in the same secret that's in the QR code. This is more convenient to scan the QR. So we've got a lot of different apps. I'm just giving a few, but there are a lot of different apps that do authentication, storing that key, and then using it to generate the codes. The most well-known is Google Authenticator, and a lot of times you'll even see the application say something like, use your Google Authenticator to generate your code. Please don't do this. It's not, it's a generic. This is an open standard. There's all sorts of implementations of it. When you say use your Google Authenticator, you're sending the message that nothing other than Google Authenticator is a valid thing to do. And that's a real shame, because there's really different ways of doing this. Do on mobile, for instance, takes a really different approach than some of the others. Some of the apps do things like show a countdown of how many seconds before you're going to have the expiration. Some of them, for some reason, don't make that real obvious at all. You just get to find out that your pace didn't work out so well. So we want to be able to evaluate which works for us. Now let's talk about hardware tokens. So that's our last category. And the term is often used as a synonym for security key. That's not technically true. There's other kinds of hardware tokens. So if that is something that you're looking for and you're checking down that column, you see, oh, great! It supports security keys. Actually, check up on that that that's what they mean and not other kinds of hardware tokens. So a security key is just a small physical device which, when it's activated, communicates the unique identifier to another device. There is a one-time setup process that you have to do on this, registering the key to each account that supports security keys. I highly recommend plural on that. Register two keys because it is a small physical object and small physical objects are really easy to lose. So you want to make sure that you do have a backup somewhere safe. And the process of using a security key is dead simple. You just get prompted, please use your key. You put it into USB slot or you tap it against an NFC sensor. You hold it near a Bluetooth antenna, and that's it. Just by it being nearby and touch the button, the work is done. So that process goes, hey, here's my password. Okay, well, give me also your security key. Okay, touch. There you go, done. Now, Yuba Key is probably the best known security key, but it's really just a brand name of a popular product line of security keys. And they are specifically USB devices. Yuba Key has one called a Neo, and that one's also an NFC device. None of Yuba Keys are a Bluetooth device. And they're all activated by touching a metal, gold metal part on them. The receiving device is something like, say, a laptop or a phone, and it just regards Yuba Key as a keyboard. It just is an NFC keyword as far as it knows. And the reason I'm emphasizing these little physical details of it, with things like a gold disk, is because not every security key actually has a gold disk. There's just a standard, but the standard doesn't say, looks like this, use gold metal. In fact, it doesn't even say use USB. So every time that you have a login screen that implies or even outright says, press the gold disk or has an icon showing something remarkably like that blue one up there. Over and over again, this happens. You're saying the same thing as with Google Authenticator. You're saying there's only one way to do this. There's only one kind. You can't look around for everything else. If this doesn't work for you, oh well. Okay, so having covered those major sets of two-factor methods, here's just a couple of other ones. I'm going to touch on them very lightly. Up Push, this is, I think, exclusive to Dual Mobile. At least it's the only one that I've seen where it's literally triggering a push notification and then it has the choice of two buttons except or decline. Decline being perhaps somebody is attacking and has triggered the request for OTP and this is your opportunity to say refuse that. That is not me. I did not request this. So it's a really straightforward, fast, easy. And it also means that the app has more control over the process. For instance, SMS is clear text, whereas the application like Dual Mobile can actually control that, make sure that it's over SSL. So fingerprint identification, and we obviously know examples right now that exist, which is MacBook Pro's Touch Bar or iOS's Touch ID swipe, done. Voice identification, as I mentioned, Amazon Home has now a voice of identification. Facial identification, we see now in iOS's face ID and of course that behavioral history is actually, this is really neat, almost anything to do with financial transactions, including credit cards, PayPal, et cetera, all have some sort of major risk detection department and this is the kind of stuff they're using. Is it typical for this user to buy products in Israel? Is it typical for this person to buy $10,000 televisions? Obviously a lot more complex than this but these are the kinds of methods as well that can be used. So a common refrain is, well, that's really just not for me. I don't either need this or I don't want this or this is too complicated or this is only for programmers or people who are absolutely under attack or really high profile. All of these myths are holding back people who do want and need to protect themselves better and don't realize that this is actually a really good approach. So who needs to factor off anyway? Everyone, every damn one of us. Two-factor mind accepts that account security needs are individual, like asking questions, who do we wish to keep things private from? What things do we want to keep private from them? How much more protected do we want them to be? What leaves us feeling less protected? Where are we most vulnerable as people? Where are the things we want to protect most vulnerable? Who's interested in those things? And what part of it would they be most interested in? What is the easiest way for them to gain the keys to your castle? And it's really easy to think about remote attacks, botnets, keyloggers, etc. But actually one of the easiest ways to get into your account is be someone who lives with you. Somebody who's used to seeing you type your password many times a day. Someone who can pick up that small physical object that is a security key. Someone who can, for instance, be the kid who really wants to bypass parental controls, waste till you're asleep and just swipe your finger across your phone. Yes, botnets are the problem. Again, every damn one. So let's talk about some of the remote attacks that do happen. Who's familiar with the breach of the Democratic National Committee? Oh, come on, everyone. Then I can skip this. Thank you for the sake of those who haven't heard. So what happened is Leon Panetta got an email. And it had a link that actually looked kind of sketchy like this. And he'd been well trained by IT. He actually forwarded and said, is this okay? Should I be clicking on this? And the IT professional responded with a very small typo. Do click on that. It's fine. It's fine. I'll be back. So we had three different directors. And thus the Democratic National Committee's emails became exposed and very likely changed the outcome of the presidential election. Not all by itself. I mean, you know, they had some help. But if only there were some way to protect against this, if only there were some way at all. So we had a year-long research on how passwords get stolen. And it found that 78,000 had been stolen via keyloggers. So just watching and logging keystrokes. 12 million were stolen via phishing. And 3.3 billion were exposed by third-party data breaches. So what can we do about these biggest threats? Fido, two-factor. Fido stands for fast idea online. It's also now the Fido Alliance. But fast idea online is just providing open specifications for what they call universal two-factor. Or universal second factor. And that's just a protocol. Here's something to think about. Two-factor auth is not two-factor auth when poor usability is making users want to run away. And a lot of the methods that we are using are just intimidating or time-consuming or a little too convoluted. Something like U2F really changes up the game. So what is different about U2F? Well, factor one can be vastly simpler. And what I mean by vastly similar? And I'm going to read this right from the Fido spec. I'm not kidding about this. A four-digit pin is appropriate when using a U2F device as your second factor. So factor two is one touch. It's basically that security key. It's got a pluggable interface, and it's interoperable with any compliant computer or device app or browser. Microsoft is already using this for Windows X. There's also any number of mobile devices that you can use this standard with already. There's over 300 U2F devices. And most importantly, for poor Leon Panetta, it cannot be phished. It cannot be phished. And also for the sake of, again, accessibility, it doesn't require any connection to phone, data, SMS, internet, any other kind of connectivity. That's huge. It's a huge change in what's possible. And it's a huge manager of one of our biggest threats. And the fact that we can also make the first factor so much easier is such a huge win for actually getting people to use this. So what do I mean by pluggable architecture? Well, you've got two sort of categories. On the one hand, you can use a variety of protocols, USB, NFC, Bluetooth. There's even a software implementation already from GitHub that you can try out. It's just using the macOS keychain to store the key. And then you get a prompt using notifications. And as well, the device can choose whatever sensor the manufacturer wants. So some common examples right now is the capacitive sensor, which is what Yuba Key uses, where just the fact of touching skin generates a teeny electrical charge that triggers the sensor. You can also use various biometric sensors. There are devices right now that when you touch it, it's actually reading your fingerprint as well. There's various other ones. So we have the ability to do a lot more mix and match. And this particularly is important because the fact that we've been using the word Yuba Key for so long as the synonym for security keys is really unfortunate because for a long time, iPhone users have been complaining that Yuba Keys don't work with iPhones. What was the woof for? And that's holding back a whole lot of people, right? U2F, the fact that you can support other protocols like Bluetooth, means that in fact you can use U2F. You just don't use it with Yuba Key. They have chosen not to use Bluetooth, but other ones are. In fact, Google has endorsed one. They have a special mode called advanced security for people who are under spirit attack and want the most constrained possible settings. And for that, they dictate that you must have two security keys and the one for iPhone users is from a company called, I'm going to mispronounce this, by tan or phytian. So you can go to the page for Google's advanced protection and see the model that they recommend for that. If you're going to use the U2F key with a browser, it does need to natively support it. There's been this myth that it only works with Chrome. Until recently, that was actually a fair myth. However, it isn't anymore. As of just a few weeks ago, Firefox has added native support and Opera already had prior to that. And of course, because this is all coming from Google, Chrome already did as well. So we have a lot more options at this point, including cross-platform. So the process for that is, hey, I'm someone authorized. Let me in, you know, let me see the secret. And then the server is saying, OK, we'll provide those two types of evidence and one of them is going to have to be U2F. OK, well, did that. That's not a match. That's untrustworthy. This is why U2F isn't fishable because it's using public key encryption and it's tying it to a particular app. A particular domain name, for instance. So that means that as soon as the device transmits something other than that valid key for that valid domain, it's not going to match. And so the server is going to reject it. At the same time, we also have, sorry, different slide. We'll get to that later. So that means that we do have this strongest defense against one of the strongest, most common, remote online attacks. With that, we're doing enter the password and then being asked to use that credential, triggering the U2F device. If it's a legitimate user, it's going to pass. On the other hand, if it's not, the key will simply not transmit anything at all. So there isn't something for an attacker to harvest by putting up a fake page. They can get your password when you put in that first factor, but there is never going to be a second factor sent to them. So the moral here is get thyself a U2F device. In fact, get two. Because remember, you want that fallback. And let's put this on the to-do list right now. That you're going to get two U2F devices sometime very soon. Unfortunately, there are some companies where it's a lot harder to get these because it's still exporting encryption, right? So you may have to look around, or if you are from another country, hey, you just happened to be in a country right now where you can buy them. And then, of course, you have to use them. So that other really big number one risk is third-party data breaches. We've been in a password reuse crisis for over a decade. Now we know why it's the number one. And those passwords are really easy to reuse because an astounding number of people for incredibly unastounding reasons, right, are reusing passwords on more than one site. Even when there's something as important as using online banking, which you would think you would want to at least have a unique one for that, but the reality is that passwords are so hard to remember and so hard to meet all the various validation rules that we put in front of them that reuse happens a lot. So each one of those breaches has been exposing passwords that have been reused. Passwords are not the problem. They are not inherently equal. It's that users are awful at remembering strong passwords and apps are awful at allowing strong passwords. Here are out of the list of the 25 top passwords. These are 10 of them. Truth. Now we are really tricky. No joke. Password is your password. It's easy to remember. What's your first step for implementing two-factor auth? We found, I hope I've convinced you that this is worth doing. First step. Make first factor less awful. Don't move on before you fix that. How to make that first factor less awful? Okay, first ruthlessly slash arbitrary restrictions on what can be a password. And the bonus one here is that you can pull out a lot of validations. Yes, people pick terrible passwords, but first we want to start by not forcing them to make terrible passwords. Communicate remaining restrictions really clearly beforehand. Yes, there are some necessary things. We definitely want to validate that they're not using one of the top five really horrible ones that we just saw. We do want to sanitize output before we save it so that we're not doing things like inviting SQL injection attacks. Hash passwords and hash them securely. Store only the hash. Never store the password. You have absolutely no need for the password. It should never be given back to the user. There is nothing about it that is a rationale for saving a password. And please, please roll out the red carpet for password managers. One of the biggest reasons is because they make it so easy to make unique strong passwords for every single app they use. And also please alert users to account changes. This is their opportunity to be told, wait, someone other than you has been trying to change the password and opportunity for them to reverse it. So every time there's a change, please send something to their phone, their email, just saying heads up. So yes, there are two factors in two factor path. And that's for a reason. Everyone's seen this XKCD, right? So the basic principle here is that all of these rules we put on passwords to make them good and strong are actually making them weak. And ones that we think are weak because they are memorable and because they are dictionary words are actually really strong if all we do is combine a bunch of them. So you can make something that's an easy phrase. I also talked to Lee Honeywell, who is an app site professional, and her recommendation was, pick something that makes you happy because you're going to be putting it in a few times. So, you know, pick like your favorite song lyric or a motivational sentence, whatever you're going to have a little jolt of joy typing in. A really important principle is that long is better than complicated. As long as you're creating that entropy, you're radically changing the situation here. Memorability is better than arcane. So just set a minimum length, and I think we just saw why, and then choose a really big maximum length. So what's a really big maximum length? Shout it out. Maybe one at a time. Someone raise a hand. Okay, answer, why? Why? Your server slows to a crawl or even can be DDoS'd by doing so. Someone else. I like that number. Yes. So there isn't a single number that is perfect, but really try to go for a couple hundred. There is a point where hashing is going to slow things down enough that you don't feel it's worth the price. But the things like restrictions of 20 characters, 30 characters, 50 characters are way too conservative. Let people do things like type in the whole, you know, bridge of their favorite song. Specify a character set and then accept any character in it. Don't throw out special characters. Don't throw out Unicode. Don't throw out two byte characters. Decide what character set you're going to accept. And then every single thing in it. That's how we're going to get that high entropy, right? And get out of the way of password managers. They can do a great job if we just allow them to. The two-factor mind is looking for ways to make both factors strong and resilient. Strengthening it first factor because first of all, it's really low hanging fruit. We don't have to make things hard on ourselves. We don't have to have new tests. We don't have to strip anything out. We don't have to have new training or support. It's really a win in so many ways. And it's also beneficial to users who don't opt into two-factor auth after you do implement it. They've gotten the benefit of the strengthening. So it's always worthwhile to start with the first factor and do everything you can to make it better. Validations. Your password can't contain part of your email address that came before the act sign. This is Microsoft. Come on. Okay. Scan down. All right. So the needing to be changed every 90 days. I guess this is assuming that the previous password had high enough entropy that it was going to take 90 days. Well, 89. No, I guess, wait, 91. Sorry. Password length must be a minimum of eight characters long. I don't know why so many sites chose eight. Where did this come from? I have no idea. Must be complex, which includes any of the below categories. European languages, uppercase characters. I've been to Europe. It turns out that some of them have a Cyrillic. They also have other characters even in, say, English language. There's more than Cyrillic. There are languages that use, for instance, diacriticals. Lots and lots of things that A through Z does not cover password history. What is up with this? The system will remember the last 10 passwords. You cannot really use these. A, what are you doing saving the last 10 passwords? Now that it's reached, you've given them 10 things! Password cannot be changed twice within 24 hours. So you're going to have to make a note in your calendar in 24 hours. Go back and start all over again. That's definitely going to happen. Your password also is not allowed to include symbols, numbers, unusual capitalization, and all these things. Titles! Okay, I'm kind of lying to you because this is Facebook's... You're an A in Canada too! It looks a lot like those other rules, right? Because they're coming from the same mindset. The same mindset of we can control things and that's worthwhile and we can predict what is good and what is bad and what is authentic. Arbitrary length constraints, like any of them, are completely pointless because when you hash, it does not matter how long or short a password is. If you're using something like Bcrypt, it's always going to come out to the same length hash anyway. The first part of the hash is just identifying what algorithm was used and then the rest of it is the hash itself. So again, allow lots of length. It's not going to harm anything. It doesn't create any more storage constraints for you. The only payment you're paying for a really long password is that initial encryption time itself. Please make security questions less awful too. That's another knowledge factor, right? Any time we're limiting answers, we're dropping entropy considerably. This is what, maybe, 15 answers. What if I'm like a shade of a color? I have absolutely no idea what the color of my child at home was. Which means that it's not a good knowledge factor because when I come back, I'm going to be baffled all over again and wonder what I chose. A lot of questions also assume things about you, like asking, you know, when did you get married or what was the birth date of your first child or where did you live as a child, assuming that apparently no one ever lives in the same place they grew up in. You know, what was the color of your first car? Not everyone drives cars or owns cars. So security questions just have so many problems that I think the really best thing we can do is throw them out entirely. They're faux security. They're security theater. We're all on board. Yay! We had a table last night where we were avidly discussing the difference between a California burrito and a Mission Burrito. So it's not necessarily tacos. But this is also really cultural-specific, right? The list of options that went along with this is probably things like hamburgers and spaghetti and burritos. There's a lot of countries where none of these would be on the top 10 list of favorite foods. So they're going to have the same problem of I'll just pick something and totally forget what it is later. The reason we want to support password managers, actually, it's run about a few reasons. First of all, there's a bunch. These are the most common ones. One password, dash link, key pass, and last pass. They're all using different approaches to do approximately the same things. So typically they do stuff like encrypting passwords for you and you can also usually plug in other knowledge factors and just save them in a generic. Automatically generating strong passwords. Usually you can select a couple of different rules to turn on or off. For instance, don't include numbers with this, do include special characters with this, etc. Automatically fill in forms. This is using a principle a little bit like UTF. If you use the password manager and allow it to do things like offer to autofill, it's only going to make the offer for the site at which that password was originally generated. So it's only going to make the offer for a site that it should have it. So it's a little bit of phishing protection. It's also giving you the ability to distribute access across multiple devices. If you're saving them just on, say, your laptop, then you've got a problem on remote. We've already seen obviously the hacks that were on iCloud. So doing something like saving it to your iCloud account or other cloud account is not necessarily going to save you. Some of them even support use of two-factor for login and putting it right in the data store. For instance, one password does this. So write in one password, you've stashed that QR code, and then when asked to fill it in, you just press a button in one password and it pops that right in. So taking care of a lot of things for you. They're simplifying that process of making passwords, but there's so much it can do. Some policies of password manager just cannot work with. Like repeating consecutive characters more than twice. I've never seen a checkbox to turn that on or off. Not contain your username or email. What is this obsession with your username and address? But I guess maybe some application could make a field for that. What is my username on every single account I've ever had everywhere? And my email addresses, which I've only ever had one. I certainly haven't had workplaces or anything that offered passwords. Please tell me all those so I can exclude them. Facilitate strong, unique, unpredictable and randomized passwords by allowing that high max length and allowing any characters in the given character set. I understand selects are for things that are hard to type. When you need people to really spell things consistently and they can't, don't ever, don't ever. They just use one pop-up. Be sure to suggest that. Oh, for the sake of the recording, I was asked, why don't they just use one pop-up? So multi-step authentication is different than multi-factor. It is multiple steps, but using the same factor rather than different factors. So something like a password plus a pin. Banks love to do this. Why is it that the ones who are storing the most sensitive information are using the shittiest? Password plus security questions, we have all unanimously agreed to never? So yeah, just adding a little nuisance factor is all that's really doing. It's slowing down login without adding any value at all. Don't bother with two-step unless you have some sort of regulatory requirement to be that dumb. I'm pretty sure banks do. A pin is just a knowledge factor and it's an appallingly weak one unless you have U2F. There's this really strong smart phone centrism in a lot of the approaches that we talked about earlier. And that's shutting out a lot of people who do need two-factor off and making a lot of assumptions on that. But it's actually ageist. It can be racist. It's definitely classist. There's also, depending on which country you're in, there may or may not be nearly the kind of support for smartphones that we think. So here we're looking at the red parts. The difference between the kind of access to smartphones you have and say the United Arab Emirates versus India, which is a major tech center, right? It's a huge population of potential customers. Only like two in ten have a smart phone. Don't make things dependent on a smart phone. In some countries where there's things like wars or coups, it's even more unlikely that you have access to a smart phone and that may be because it's expensive or it may be because the infrastructure is really not there to have mobile connectivity or it could be that it's so monitored at this point that it's unsafe to use. So we really cannot be depending on these as well. So, I'm going to change gears for a second. Has everyone seen this? Okay, you have to see this. Bright Lights is the documentary about Carrie Fisher and her mom Debbie Reynolds. And there's this one scene that I actually love. Carrie says, mother, you cannot keep that phone. It's a flip phone. It's from when they first invented cell phones. It works fine. It's ridiculous. Just dandy. Debbie's the best. Yeah, some people don't have a smart phone because they just don't need it. And that's especially true of singer-citizens. But what I do notice here is, so the green one is mobile phones and the blue is smart phones. So don't assume that singers don't have a phone. Many of them do. When they go into their 70s, almost all of them do. It's not a smart phone. Get out of the way of password managers. Don't fuck with copy-paste. The whole circus is in. So, I'm going to ask you to stand up if you can. We're all going to say this together. Ready? One, two, three. I am able to make the world a better place for at least one vulnerable person who needs resistant, resilient online security. Wherever possible, I use, advocate, communicate, enable and increase access for long, unique, unpredictable knowledge factors, FIDO, U2F devices, and any incremental step forward. That's two factor off mine.