Hunter2: A Symphony of Password Horror
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Ryan, Lilly
The year is 2017. We have hoverboards, jetpacks, solar-powered cars, and also so many awful passwords that it’s become trivial for pretty much anyone to have their accounts compromised. We’ve got passwords for our passwords. Eight-year-olds with a dictionary and a set of dice can generate mathematically stronger passwords than most corporations that have your credit card details. We spend our days wandering through endless forests of requirements to come up with something that contains no more than twelve letters, a special character, the eye of a newt, and at least one uppercase letter, only to be emailed it back in plaintext if you forget it. And then it goes on a Post-It note on a monitor. Do not despair - this talk is here to help! From beginners to experts, all technical folk have the power to build a post-password future. Lilly, an engineer and historian, will guide you through the history of how we got ourselves into this state, and explain why major companies still think that the best way to keep your stuff secure is to poke their heads out of the tree-house and ask you for the secret word. She will then hand you strong technical tools to help your clients and colleagues understand why there are better things out there than “Welcome1!”, and help you work together to bring a small ray of sunshine into our password-saturated world.
 I feel free to wave out if the audio quality is not great. Okay. Thank you very much for coming along. I'm Lily. What I'm about to share with you is a horror story about passwords. So what about the bananas? They have nothing to do with this talk. I'm using them as slide clickers, which I'm hoping will work. Oh, no. These don't. Oh my gosh. What happened to the dead bananas? Hang on. Do you think we have a loose banana? No, loose bananas. There's no good. Oh well. We'll see how we go. Oh, I know why they're not working. Okay. Cool. All right. Problem solved. The bananas are functional. This is my Twitter handle in case you want to be friends on the internet. And as I said, this is a horror story about passwords. And drawing on good horror stories, I'm going to use images here from the 1922 movie Nosferatu, which is the first one I've ever made. And I'm using these because, firstly, like vampires, the story of passwords is life-draining and keeps me awake at night in terror. And secondly, because most password policies are about as well-written as Twilight. Oh. I'm going to be mentioning a few Django-specific packages in this talk. And a lot of other blog posts and news articles and things like that. So to save you taking pictures of anything that you want to look up later while I'm talking, I've collected all of my research and everything that I've mentioned in this talk that I'm going to mention. And I've put it at this link on my website. And I'll share this link again at the end of the talk so don't panic. Okay. If you follow tech news in any capacity, you hear every day about databases. Username and password combinations being dumped out on the public internet. And these reports usually come with a heavy use of the word cyber and maybe a picture of someone in a hoodie or a screen with lots of zeros and ones. And maybe the word password in the middle of it somewhere because the cyber is very scary. And if you've been using the internet for a while, you know that passwords kind of suck. And if you've been working in software for a while, you know that passwords really suck. We all kind of take the presence of passwords for granted. You get an email account, that's a password. You get hired for a new job and you need to get into your work account, that's another password. You sign up for Netflix and that's yet another password and probably a shared password because you'll share that account with everyone in your household. And you might put that on the fridge next to the Wi-Fi password, which you also hopefully have. We all know that the most common passwords are still password and 123456. And we know that most people use the same password for multiple accounts because it's easier to remember that way. And we know that a non-zero number of people put their password on a post-it note on their monitor so that they can remember it. And despite all of the interesting and glamorous new software hacks that make the news, password database leaks are still the most common way to, quote-unquote, get hacked. Restrictive password policies mean that people make poor password choices and they repeat their passwords. The choices we make with how we store these passwords as software developers contributes to a lot of this information being leaked online. And the fact that many services still have passwords as their only form of authentication contributes to passwords being a single point of failure. But despite being pretty basic in some ways, all of these things are really important. And how we got ourselves into this password mess is important. And I want to tell you about how we got to this point for two reasons. Firstly, in addition to being a person who does things with code, I am also a historian, which is a story for another time. And I'm interested in why we got to where we are and, more importantly, why we still keep doing this to ourselves. And the second and probably more urgent reason to tell you about passwords is because I'm bored of hearing about them all the time. Passwords are pretty bad technology with several different bad implementations. And I would rather be doing something more exciting with my time than running around cleaning up the mess left by passwords. And the reason I want to tell you folks about this is because we're the ones who can really do something about it. We are your IT folk and your testers and your system administrators. Sometimes we're consultants, sometimes we'll work in-house, and sometimes we're the ones who get called up by our families to help them install antivirus and back up their photographs. We are the ones who have the influence and the ability to do something about this. So if you're as tired as I am of hearing about passwords being leaked and accounts being hacked, I'd really implore you to join me and help fix this for everybody. So here is a horrible story of awful passwords, followed by a list of five ways that we can stop doing this to ourselves over and over and over again, because we deserve nice things. Okay, once upon a time there was a password, and this password was open sesame, and it protected a cave where a bunch of thieves were hiding the treasure that they had stolen. There was no two-factor authentication on this cave. One day a guy called Ali Baba was in the neighborhood, and he saw the thieves saying open sesame and getting into the magic cave. So he exploited this by waiting until they had left, walking up to the cave and saying open sesame, and he got in, and he had a look around, and he took a bag of coins that the thieves had stolen, and he left the cave and he bought a cool new house. The thieves came after him to kill him and to get back what he'd stolen. And after a protracted and dramatic series of events, Ali Baba managed to kill all of the thieves until he was the only one who knew the password to this magic cave, which is really how the first thief should have kept it at the start. So that story, which normally goes by the name of Ali Baba and the 40 thieves, is allegedly thousands of years old. It is at least 300 years old, which is still pretty old. Here's another one that's less old than that, but still slightly older than the Internet. Once upon a time, in about the coldest part of the Cold War, there was a President of Anamerica. This President decided that the United States stockpile of nuclear weapons probably needed some kind of controls so that they didn't get set off by accident or by just anyone, because that would probably be bad. So the President asked his Secretary of Defense to make that happen, and the Secretary of Defense made it mandatory for there to be a passcode lock on the big red button that could make the world explode, so that it would have to be communicated to people and entered deliberately before they were really sure that they wanted all of the fallout from that decision. The guy who was in charge of strategic air commands thought that this was a ridiculous system, because it got in the way of making it easy to push the big red button, and also because passcodes are annoying to remember. So he changed all of the passcodes on all of the copies of the big red button to a string of eight zeros. And this is why I'm pretty sure that we're all living in some kind of alternate splinter universe, because by some miracle we didn't all die. And because the world survived to make more bad password decisions, here's one more story for you. Once upon a time, there was a guy called Alan, who is a PhD student at MIT. MIT had a computer, and much like my childhood, there was only one of them, and it was in very high demand, because everybody wanted to use it, presumably a lot like my childhood, because they all wanted to play Rollercoaster Tycoon. So MIT decided what most parents decide, which is the sharing is nice, and so they divided up computer time among the MIT researchers into several hour blocks. And to stop people taking over other people's blocks of time, they put a time lock system on the computer, which meant that at the end of your allocated time, you would be logged out, and then the next person could come and log in. Alan had been given four hours a week on this computer, which was actually pretty good for that point in time, but not good enough for the research that Alan was doing in Alan's opinion. So he had a look around on the computer, and he discovered the file that kept all of the usernames and passwords in it. This file was called Passwords. And it was in plain text, because this was the first time that anybody had ever thought to put passwords on a computer. And they clearly hadn't heard the story of Alibaba and the 40 thieves. So Alan printed out this file, and then whenever he'd run out of his four hours, he would just log out and he could log in as somebody else. And he also dumped this data for all of the other PhD students at MIT to use, because he was nice, and also because if everyone was doing it, it would be harder to pinpoint it on him. Alan got away with it, and people still get away with it. The ancient Greek warfare strategist, Anius Tacticus, once said that a good password should be easy to remember. The login system for my bank once said that any good password should be between 8 and 16 characters. And contain at least one uppercase and one lowercase letter, a number, and one special character. As long as that special character is something like at or dollar sign, and not something weird like a tilde, or something that will break that database, like a semicolon. And passwords which use characters or fancy accented parts, or characters with fancy umlas, or accented parts, or, God forbid, emoji, are very bad passwords who will be sent to bed without dessert. Or the ability to pay your bills. I used the past tense there because when I read this, I switched banks. The point in telling you all of these stories is that we never really got to this point with regard to passwords. We have always been exactly where we are. We've just made passwords more and more mandatory to get anything done when they were already kind of a giant pain in the butt. But security is also something that most people don't think about at all. And we all lived horribly ever after. The end. Because this whole situation is kind of awful most of the time. But we know that we can do better. We enable multi-factor authentication on all of our accounts. We use a password manager and we generate long passwords. And we know that really the length of a password combined with unpredictability, like a bunch of random words, makes that password harder to crack, rather than a short non-dictionary word with special characters. But not everybody knows that. And it's everybody else who builds and uses the internet the majority of the time, not just the people in this room. So if we want to get it right for us, we have to make it right for them, too. So here are some recommendations for five simple things that we can do as technical people to make this ever so slightly better. All right. So basically, sultz and hash any passwords that your system stores. I know that this particular point is brought up in most talks about passwords, but the reason I'm bringing it up again is because a scary number of websites and services still don't do this. If you're working on a system that doesn't do this, please make it do this. And for those who are unsure how to do this, here's a quick overview. Here is an average password. Someone uses this password for an account on your system, so your system needs to remember it. However, we don't want to store this in plain text because if we do that, then the PhD students of the... The PhD student-allens of the world will do what they've been doing since the 1960s. So we need to add some sultz. Sultz in this case means a random string that you append to a password before you store it in your system, which should ideally be a little bit long. And it should also be unique, meaning that you don't use the same sultz on all the passwords in your system. And maybe keep it to yourself. Don't publish this anywhere particularly important. Then before you store it, you run the password and the sultz together through a hashing algorithm, get the output of that algorithm, maybe run it again a few times, get the output of that, and then store that in your database. This example uses SHA-256 with only one round of hashing. I know that people have lots of opinions about which hashing algorithms are the best, but there are two overall don'ts, regardless of which one that you use. Firstly, please don't try to write your own hashing algorithm. There are plenty out there that are very good and were written by people with mathematics PhDs. Secondly, please don't use SHA-1 as your hashing algorithm, because even though it was developed by people with mathematics PhDs, it's a pretty old algorithm and insecure by today's standards. So if you hash and sult all the passwords that you're storing, even if your password database gets leaked, it will be really difficult for an attacker to reverse that password, because they won't be able to guess the password just from its hash by itself, and they will also have to guess the sult that you used for each password, and how many times you went around, which makes the task approximately infinity times more difficult. And look, at the very, very least, please don't let your clients store their passwords in plain text. The good news is that if you're wondering how to do this and use Django, which I suspect some of you might, Django does this by default. Instead of having to bring all of this together manually, which is also usually not the best idea, Django uses PBKDF2 to take care of all the hashing and the salting, and it will do this multiple times for you. PBKDF2 is slow to compute, but you want this, because it also means that it takes a really, it takes infinity times longer than that for someone else to run all of the possible permutations of the salts and the hashes and the rounds. So even if your database is leaked, your users should still be reasonably well protected. And if you don't want to use the Django default, you can also use Album2 or Becrypt by changing the password hashes setting. And in my resources, I've honestly literally just added a link to the docs because the docs are really good. And if I explain more, I would just be reading them to you. Let's not do that. Another thing that you can do on a Django project to help with passwords is to implement a lockout on the number of password attempts that people have when they're trying to log in. So if someone does try to log in maliciously, they only have a, they won't get to try very many times. And they won't get to hammer your service with failed requests. Django access has you covered there. According to their docs, they're called access because partly because access sounds like access. And also because access is a thing that you can use to hack stuff. And they want to prevent hacking. And one more thing, while we're here, make sure that your service uses HTTPS when you handle login because it's no good to do all of this fancy hashing and salting and stuff if the password gets sent to you in plain text the first time. Okay, secondly, implement multi-factor authentication on every system that you work on that you can. Passwords alone are not enough anymore. Multi-factor authentication means that we need a password, a.k.a. something we know. And another piece of information, a.k.a. something that we have before we can let you into your account. Universal second factor or U2F is probably, in my opinion, the best second factor of implementation that there is. So if you can implement support for it, please do it. U2F, for those who haven't had a chance to work with it yet, requires a physical key, like a UV key, which speaks directly to your browser and uses public key cryptography to uniquely identify you when you try to log into your account. It also requires you to touch the keypad on it once, much like a banana, to prove that there's a live human at the other end, which means that robots can't just try and run this over and over again. You actually need that capacitive touch. There's also a huge amount of ridiculously cool stuff going on under the hood of that. So if you want to learn more, there's a link to the UV key white paper in my notes, or come and find me afterwards because I really enjoy talking about UV key. And, okay, yes, it's a physical key. I know this is annoying, but it can be used across a bunch of different sites without reusing credentials, which is a lot unlike those key ring full of RSA tokens that you used to have, which is pretty cool. And U2F is also an open source protocol, which means that anyone should be able to pick it up and support it. Google and Facebook do this. So do Fastmail, so do GitHub, so do Dropbox, so do others, and so could you. There are a couple of other software token ways to do multi-factor authentication, but the most common is TOTP, which is a time-based one-time password, which generates a one-time password, if you could believe that. It's usually six digits long, and it's based on a shared secret key and the current time. And these temporary passwords usually don't live for very long, between about 30 seconds and five minutes, depending on your config. You can deliver this token to a user in a number of ways. Some people like to write their own apps that will generate the token. Some people will use third-party apps like Google Authenticator, and a lot of services send these sorts of tokens via SMS, but I would not recommend doing that because it's trivially easy for a dedicated attacker to clone a copy of your SIM or get a hold of that SMS in some other way. It's usually not encrypted if they really wanted to do that. SMS is a second-factor delivery method, has been deprecated by many people in lots of places and some instances officially, so avoid SMS if you can. But multi-factor authentication for Django is really easy, which is great. Marcus Holtman gave a great talk at DjangoCon Australia last year, which there is also a link to in my notes, about how to implement two-factor authentication in Django. So instead of repeating that whole talk, I've added the link, and you can go and look that up. But the TLDR is that the Django two-factor auth package contains everything you need to implement, U2F, TOTP, a few other things, via Django app. It's really cool. Go and check that out. Okay, thirdly, make more than one multi-factor authentication method available for people who want to use it. U2F and a one-time password, plus a password itself, make things even harder for your account to be broken into by somebody else. Not all services support multiple second factors, and I can understand how turning that on by default for many people would be kind of annoying. But on the other hand, I'm the kind of systems administrator who would really like this kind of option to be available for super users like me. There have been heaps of headlines over the last few years about how this or that technology is going to be the password killer. But honestly, I think that what's going to kill it is a combination of different factors which correspond to a thing you know and a thing you have, and that's the way it's going to be. Eventually, this means that one of these things doesn't necessarily need to be a traditional password. It could be a pattern or a sequence or something else that you can know. And as an aside, because I don't have time to cover absolutely everything about authentication in 30 minutes, supporting SAML and OAuth and other federated login systems is also a really good idea. In my notes, I've added a link to Fraser Tweedel's PyCon Australia talk on federated identity, which was given this year. It's a really good video. And he goes into all of these technologies in depth. It's from last week. It's pretty current. So go and check that out. But please remember, even if you turn on all of the MFA, breaking into these accounts is still not impossible. Nothing is ever 100% secure. It's not going to happen. That said, implementing this stuff does make it a hell of a lot harder for your users to have their accounts compromised by the average attacker. Fourthly, if that's a thing, help your clients write their password policies. Good password policies will get rid of the special character requirements in favour of a mandatory minimum password length and a randomness checker. Strictly speaking, the best passwords are long and hard to predict. It doesn't matter what kinds of special characters and numbers that they have in them. You usually see mandatory maximum lengths of 16, sometimes 20 characters, but I encourage you if you can to ditch these entirely. Longer is usually stronger. And mandatory minimum length is the best way to get people to generate strong ones. And tell your clients about Diceware passwords, by which I mean passwords made up of four or more random words, which are easy for humans to remember in a sequence, but hard for computers to guess. One of the slides here is an example of one that I generated last week. This is a 40 character password. It isn't a predictable sentence. It's not a quote from Shakespeare or something like that. But it is definitely something that I could memorise if I really had to. Please make sure that your password policies support passwords that look like this one. And don't reject it as weak, because there are no symbols or numbers in it. Some password managers will generate passwords that look like this, but if you don't have that option and you need to come up with one for yourself, I like to think of something that was on the shelf in my bedroom when I was a kid, you know, a sequence of things in the order that I remember them. Or people suggest making up stories about the sequence of words to help you remember all of these sorts of things. Pretty much anything that is a sequence that only you could think of. If you can get it generated by a machine, that's probably the best way to do it. But good password policies are meaningless if you don't bring your users along for the ride. And using diceware passwords is also pretty meaningless if you don't use a password manager to record them, because even though they're long and easier for humans to remember, they're still really annoying, and we still have so many accounts in our day-to-day lives that people will fall into that old trap of just repeating them over and over again. And someone's unhashed, unsalted database will get leaked, it's inevitable, and that password will become public. So here's point 4A, which is education. For any of this to be really effective, you need to educate people about good password hygiene, and tell them about password managers. And by this, I don't mean just your users specifically, but also your friends and your family, because good password practice goes way outside the scope of your work project. This is a long-term, real-life, meat-space effort. Please gift people subscriptions or link them key pass, key pass X, teach people how to use password managers so that we can write password policies that generate strong passwords. I think a password manager has kind of a band-aid on the whole problem of passwords. They don't really solve the fact that we have way too many passwords to deal with on a day-to-day basis, but as the name suggests, they do make passwords easier to manage. Long strings like the ones I'm recommending are not so easy to handle without them. There's last pass and one password and key pass and dash lane and many. All of them have their strengths and their weaknesses, but using any one of them is better than using none at all. So get out there and start showing people how to use them. Back within the scope of your work project, a quick and easy way to educate your users about strong passwords is to give them automatic client-side feedback on the passwords that they give you when you're signing up and account with them or when they're changing. Dropbox came up with a really great tool called ZXCVBM, which gives instant feedback to your users on the strengths of the passwords that they're trying to give you. And it determines strengths on how long a string would take to break in terms of time, rather than what kinds of uppercase letters and lowercase letters and symbols that it uses. It also contains a really good dictionary of common words and leaked passwords to help people avoid those. And it's been ported to Python and a lot of other languages, so go and try that out. Point five, rethink the idea of working on systems that are using biometrics as the only form of authentication. This is the medium-length form of a particular rant of mine, but the basic thrust of it is that if your password gets compromised, you can change it. If your fingerprints get compromised, it is very hard to grow new fingers. And when I say compromised, biometrics can be compromised in many more ways than a straight-up password can. Passwords get leaked in database dumps and on post-it notes, or actually my Uber driver told me hers on the way back from the airport. But we keep coming up with new ways to steal and fake biometric information all the time. Late last year, Adobe released a new piece of software called Voco, which can generate samples of a human voice after being fed about 20 minutes of speaking data. So when I don't have an epic cold, I'm someone who narrates audio books in my spare time. So I can really appreciate the idea of not needing to be called back to the studio to do an extra 10 minutes of recording. But I am also someone who works really closely with authentication software, and I can see the potential for someone to get one of my recordings, even the recording of this talk, and feed it to Voco, and then have it rattle off the passphrase for my phone banking account. And for anyone thinking of doing this, you won't be able to do this with that service, or with any other service I use, please do not try. But if you have ever given a conference talk or appeared in a recording, be aware of what is becoming possible. Don't enroll yourself in this stuff, and don't build it into your systems. And there's more good news for a given value of good. In January, some researchers in Japan discovered that the average smartphone camera can capture detailed images of somebody's fingerprints from three metres away, if the lighting is really good. And this means that you can get fingerprint information from any Facebook selfie where you throw up a peace sign, or you can steal a fingerprint pattern of a public figure if they were photographed close enough and they weren't wearing gloves. Not unrelated, a lot of recent breakthroughs in 3D printing and medical technology mean that we are getting better at printing human skin, which is great news for a lot of people, but it also means that all of that Gadagastyle biometric fakery just got real. But digital stealing and faking is the softer approach. In 2005, an accountant in Malaysia parted company with one of his fingertips. After the people who stole his Mercedes from him at gunpoint realised that they needed his fingerprint to start it. Slightly less violently, there was the story of the six-year-old girl in Arkansas who used her mother's fingerprint while she was asleep to unlock her iPhone and rack up about $250 worth of Pokemon toys. Bimetrical looks really cool in the movies, but the movies are also where people end up with their eyeballs being removed to bypass it. And look, I mean, there's a lot of really cool stuff about living in the future, but I don't want to bring this part into it. So, if you're working on a project that is thinking about it, see if there's something else there that might fit that need instead. And if you must use biometrics, make sure that they are only one part of several factors needed to authenticate because they're very easy to hack both technologically and socially. Six-year-olds can do it. So to recap, salt and hash, implement MFA, support U2F, enable more than one MFA, write proper password policies and educate people about passwords, and say no to standalone biometrics. And here's that link again to my notes and my resources in case you want to take a picture and look it up later. And I'll tweet it just in case. I know that these are only really small things, and this seems like really basic stuff, and this stuff won't make the world perfect, and they won't make people completely unhackable, but they'll make the state of things a tiny bit better than the way that it was. I would love a happy ending to the story of passwords, so please help me write one. Thank you.
 I feel free to wave out if the audio quality is not great.  Okay.  Thank you very much for coming along.  I'm Lily.  What I'm about to share with you is a horror story about passwords.  So what about the bananas?  They have nothing to do with this talk.  I'm using them as slide clickers, which I'm hoping will work.  Oh, no.  These don't.  Oh my gosh.  What happened to the dead bananas?  Hang on.  Do you think we have a loose banana?  No, loose bananas.  There's no good.  Oh well.  We'll see how we go.  Oh, I know why they're not working.  Okay.  Cool.  All right.  Problem solved.  The bananas are functional.  This is my Twitter handle in case you want to be friends on the internet.  And as I said, this is a horror story about passwords.  And drawing on good horror stories, I'm going to use images here from the 1922 movie Nosferatu,  which is the first one I've ever made.  And I'm using these because, firstly, like vampires, the story of passwords is life-draining and keeps me awake at night in terror.  And secondly, because most password policies are about as well-written as Twilight.  Oh.  I'm going to be mentioning a few Django-specific packages in this talk.  And a lot of other blog posts and news articles and things like that.  So to save you taking pictures of anything that you want to look up later while I'm talking,  I've collected all of my research and everything that I've mentioned in this talk that I'm going to mention.  And I've put it at this link on my website.  And I'll share this link again at the end of the talk so don't panic.  Okay.  If you follow tech news in any capacity, you hear every day about databases.  Username and password combinations being dumped out on the public internet.  And these reports usually come with a heavy use of the word cyber and maybe a picture of someone in a hoodie or a screen with lots of zeros and ones.  And maybe the word password in the middle of it somewhere because the cyber is very scary.  And if you've been using the internet for a while, you know that passwords kind of suck.  And if you've been working in software for a while, you know that passwords really suck.  We all kind of take the presence of passwords for granted.  You get an email account, that's a password.  You get hired for a new job and you need to get into your work account, that's another password.  You sign up for Netflix and that's yet another password and probably a shared password because you'll share that account with everyone in your household.  And you might put that on the fridge next to the Wi-Fi password, which you also hopefully have.  We all know that the most common passwords are still password and 123456.  And we know that most people use the same password for multiple accounts because it's easier to remember that way.  And we know that a non-zero number of people put their password on a post-it note on their monitor so that they can remember it.  And despite all of the interesting and glamorous new software hacks that make the news,  password database leaks are still the most common way to, quote-unquote, get hacked.  Restrictive password policies mean that people make poor password choices and they repeat their passwords.  The choices we make with how we store these passwords as software developers contributes to a lot of this information being leaked online.  And the fact that many services still have passwords as their only form of authentication contributes to passwords being a single point of failure.  But despite being pretty basic in some ways, all of these things are really important.  And how we got ourselves into this password mess is important.  And I want to tell you about how we got to this point for two reasons.  Firstly, in addition to being a person who does things with code, I am also a historian, which is a story for another time.  And I'm interested in why we got to where we are and, more importantly, why we still keep doing this to ourselves.  And the second and probably more urgent reason to tell you about passwords is because I'm bored of hearing about them all the time.  Passwords are pretty bad technology with several different bad implementations.  And I would rather be doing something more exciting with my time than running around cleaning up the mess left by passwords.  And the reason I want to tell you folks about this is because we're the ones who can really do something about it.  We are your IT folk and your testers and your system administrators.  Sometimes we're consultants, sometimes we'll work in-house, and sometimes we're the ones who get called up by our families to help them install antivirus and back up their photographs.  We are the ones who have the influence and the ability to do something about this.  So if you're as tired as I am of hearing about passwords being leaked and accounts being hacked, I'd really implore you to join me and help fix this for everybody.  So here is a horrible story of awful passwords, followed by a list of five ways that we can stop doing this to ourselves over and over and over again, because we deserve nice things.  Okay, once upon a time there was a password, and this password was open sesame, and it protected a cave where a bunch of thieves were hiding the treasure that they had stolen.  There was no two-factor authentication on this cave.  One day a guy called Ali Baba was in the neighborhood, and he saw the thieves saying open sesame and getting into the magic cave.  So he exploited this by waiting until they had left, walking up to the cave and saying open sesame, and he got in, and he had a look around, and he took a bag of coins that the thieves had stolen, and he left the cave and he bought a cool new house.  The thieves came after him to kill him and to get back what he'd stolen.  And after a protracted and dramatic series of events, Ali Baba managed to kill all of the thieves until he was the only one who knew the password to this magic cave, which is really how the first thief should have kept it at the start.  So that story, which normally goes by the name of Ali Baba and the 40 thieves, is allegedly thousands of years old.  It is at least 300 years old, which is still pretty old.  Here's another one that's less old than that, but still slightly older than the Internet.  Once upon a time, in about the coldest part of the Cold War, there was a President of Anamerica.  This President decided that the United States stockpile of nuclear weapons probably needed some kind of controls so that they didn't get set off by accident or by just anyone, because that would probably be bad.  So the President asked his Secretary of Defense to make that happen, and the Secretary of Defense made it mandatory for there to be a passcode lock on the big red button that could make the world explode, so that it would have to be communicated to people and entered deliberately before they were really sure that they wanted all of the fallout from that decision.  The guy who was in charge of strategic air commands thought that this was a ridiculous system, because it got in the way of making it easy to push the big red button, and also because passcodes are annoying to remember.  So he changed all of the passcodes on all of the copies of the big red button to a string of eight zeros.  And this is why I'm pretty sure that we're all living in some kind of alternate splinter universe, because by some miracle we didn't all die.  And because the world survived to make more bad password decisions, here's one more story for you.  Once upon a time, there was a guy called Alan, who is a PhD student at MIT.  MIT had a computer, and much like my childhood, there was only one of them, and it was in very high demand, because everybody wanted to use it, presumably a lot like my childhood, because they all wanted to play Rollercoaster Tycoon.  So MIT decided what most parents decide, which is the sharing is nice, and so they divided up computer time among the MIT researchers into several hour blocks.  And to stop people taking over other people's blocks of time, they put a time lock system on the computer, which meant that at the end of your allocated time, you would be logged out, and then the next person could come and log in.  Alan had been given four hours a week on this computer, which was actually pretty good for that point in time, but not good enough for the research that Alan was doing in Alan's opinion.  So he had a look around on the computer, and he discovered the file that kept all of the usernames and passwords in it.  This file was called Passwords.  And it was in plain text, because this was the first time that anybody had ever thought to put passwords on a computer.  And they clearly hadn't heard the story of Alibaba and the 40 thieves.  So Alan printed out this file, and then whenever he'd run out of his four hours, he would just log out and he could log in as somebody else.  And he also dumped this data for all of the other PhD students at MIT to use, because he was nice, and also because if everyone was doing it, it would be harder to pinpoint it on him.  Alan got away with it, and people still get away with it.  The ancient Greek warfare strategist, Anius Tacticus, once said that a good password should be easy to remember.  The login system for my bank once said that any good password should be between 8 and 16 characters.  And contain at least one uppercase and one lowercase letter, a number, and one special character.  As long as that special character is something like at or dollar sign, and not something weird like a tilde, or something that will break that database, like a semicolon.  And passwords which use characters or fancy accented parts, or characters with fancy umlas, or accented parts, or, God forbid, emoji, are very bad passwords who will be sent to bed without dessert.  Or the ability to pay your bills.  I used the past tense there because when I read this, I switched banks.  The point in telling you all of these stories is that we never really got to this point with regard to passwords.  We have always been exactly where we are.  We've just made passwords more and more mandatory to get anything done when they were already kind of a giant pain in the butt.  But security is also something that most people don't think about at all.  And we all lived horribly ever after.  The end.  Because this whole situation is kind of awful most of the time.  But we know that we can do better.  We enable multi-factor authentication on all of our accounts.  We use a password manager and we generate long passwords.  And we know that really the length of a password combined with unpredictability, like a bunch of random words, makes that password harder to crack, rather than a short non-dictionary word with special characters.  But not everybody knows that.  And it's everybody else who builds and uses the internet the majority of the time, not just the people in this room.  So if we want to get it right for us, we have to make it right for them, too.  So here are some recommendations for five simple things that we can do as technical people to make this ever so slightly better.  All right.  So basically, sultz and hash any passwords that your system stores.  I know that this particular point is brought up in most talks about passwords, but the reason I'm bringing it up again is because a scary number of websites and services still don't do this.  If you're working on a system that doesn't do this, please make it do this.  And for those who are unsure how to do this, here's a quick overview.  Here is an average password.  Someone uses this password for an account on your system, so your system needs to remember it.  However, we don't want to store this in plain text because if we do that, then the PhD students of the...  The PhD student-allens of the world will do what they've been doing since the 1960s.  So we need to add some sultz.  Sultz in this case means a random string that you append to a password before you store it in your system, which should ideally be a little bit long.  And it should also be unique, meaning that you don't use the same sultz on all the passwords in your system.  And maybe keep it to yourself.  Don't publish this anywhere particularly important.  Then before you store it, you run the password and the sultz together through a hashing algorithm, get the output of that algorithm,  maybe run it again a few times, get the output of that, and then store that in your database.  This example uses SHA-256 with only one round of hashing.  I know that people have lots of opinions about which hashing algorithms are the best,  but there are two overall don'ts, regardless of which one that you use.  Firstly, please don't try to write your own hashing algorithm.  There are plenty out there that are very good and were written by people with mathematics PhDs.  Secondly, please don't use SHA-1 as your hashing algorithm,  because even though it was developed by people with mathematics PhDs,  it's a pretty old algorithm and insecure by today's standards.  So if you hash and sult all the passwords that you're storing,  even if your password database gets leaked, it will be really difficult for an attacker to reverse that password,  because they won't be able to guess the password just from its hash by itself,  and they will also have to guess the sult that you used for each password,  and how many times you went around, which makes the task approximately infinity times more difficult.  And look, at the very, very least, please don't let your clients store their passwords in plain text.  The good news is that if you're wondering how to do this and use Django,  which I suspect some of you might,  Django does this by default.  Instead of having to bring all of this together manually,  which is also usually not the best idea,  Django uses PBKDF2 to take care of all the hashing and the salting,  and it will do this multiple times for you.  PBKDF2 is slow to compute, but you want this,  because it also means that it takes a really, it takes infinity times longer than that  for someone else to run all of the possible permutations of the salts and the hashes and the rounds.  So even if your database is leaked, your users should still be reasonably well protected.  And if you don't want to use the Django default, you can also use Album2 or Becrypt  by changing the password hashes setting.  And in my resources, I've honestly literally just added a link to the docs  because the docs are really good.  And if I explain more, I would just be reading them to you. Let's not do that.  Another thing that you can do on a Django project to help with passwords  is to implement a lockout on the number of password attempts that people have when they're trying to log in.  So if someone does try to log in maliciously, they only have a, they won't get to try very many times.  And they won't get to hammer your service with failed requests.  Django access has you covered there.  According to their docs, they're called access because partly because access sounds like access.  And also because access is a thing that you can use to hack stuff.  And they want to prevent hacking.  And one more thing, while we're here, make sure that your service uses HTTPS when you handle login  because it's no good to do all of this fancy hashing and salting and stuff  if the password gets sent to you in plain text the first time.  Okay, secondly, implement multi-factor authentication on every system that you work on that you can.  Passwords alone are not enough anymore.  Multi-factor authentication means that we need a password, a.k.a. something we know.  And another piece of information, a.k.a. something that we have before we can let you into your account.  Universal second factor or U2F is probably, in my opinion, the best second factor of implementation that there is.  So if you can implement support for it, please do it.  U2F, for those who haven't had a chance to work with it yet, requires a physical key, like a UV key,  which speaks directly to your browser and uses public key cryptography to uniquely identify you when you try to log into your account.  It also requires you to touch the keypad on it once, much like a banana, to prove that there's a live human at the other end,  which means that robots can't just try and run this over and over again.  You actually need that capacitive touch.  There's also a huge amount of ridiculously cool stuff going on under the hood of that.  So if you want to learn more, there's a link to the UV key white paper in my notes,  or come and find me afterwards because I really enjoy talking about UV key.  And, okay, yes, it's a physical key.  I know this is annoying, but it can be used across a bunch of different sites without reusing credentials,  which is a lot unlike those key ring full of RSA tokens that you used to have, which is pretty cool.  And U2F is also an open source protocol, which means that anyone should be able to pick it up and support it.  Google and Facebook do this.  So do Fastmail, so do GitHub, so do Dropbox, so do others, and so could you.  There are a couple of other software token ways to do multi-factor authentication,  but the most common is TOTP, which is a time-based one-time password, which generates a one-time password, if you could believe that.  It's usually six digits long, and it's based on a shared secret key and the current time.  And these temporary passwords usually don't live for very long, between about 30 seconds and five minutes, depending on your config.  You can deliver this token to a user in a number of ways.  Some people like to write their own apps that will generate the token.  Some people will use third-party apps like Google Authenticator,  and a lot of services send these sorts of tokens via SMS, but I would not recommend doing that  because it's trivially easy for a dedicated attacker to clone a copy of your SIM  or get a hold of that SMS in some other way.  It's usually not encrypted if they really wanted to do that.  SMS is a second-factor delivery method, has been deprecated by many people in lots of places and some instances officially,  so avoid SMS if you can.  But multi-factor authentication for Django is really easy, which is great.  Marcus Holtman gave a great talk at DjangoCon Australia last year, which there is also a link to in my notes,  about how to implement two-factor authentication in Django.  So instead of repeating that whole talk, I've added the link, and you can go and look that up.  But the TLDR is that the Django two-factor auth package contains everything you need to implement,  U2F, TOTP, a few other things, via Django app.  It's really cool. Go and check that out.  Okay, thirdly, make more than one multi-factor authentication method available for people who want to use it.  U2F and a one-time password, plus a password itself,  make things even harder for your account to be broken into by somebody else.  Not all services support multiple second factors,  and I can understand how turning that on by default for many people would be kind of annoying.  But on the other hand, I'm the kind of systems administrator who would really like this kind of option to be available for super users like me.  There have been heaps of headlines over the last few years about how this or that technology is going to be the password killer.  But honestly, I think that what's going to kill it is a combination of different factors  which correspond to a thing you know and a thing you have, and that's the way it's going to be.  Eventually, this means that one of these things doesn't necessarily need to be a traditional password.  It could be a pattern or a sequence or something else that you can know.  And as an aside, because I don't have time to cover absolutely everything about authentication in 30 minutes,  supporting SAML and OAuth and other federated login systems is also a really good idea.  In my notes, I've added a link to Fraser Tweedel's PyCon Australia talk on federated identity,  which was given this year. It's a really good video.  And he goes into all of these technologies in depth.  It's from last week. It's pretty current. So go and check that out.  But please remember, even if you turn on all of the MFA, breaking into these accounts is still not impossible.  Nothing is ever 100% secure. It's not going to happen.  That said, implementing this stuff does make it a hell of a lot harder for your users to have their accounts compromised by the average attacker.  Fourthly, if that's a thing, help your clients write their password policies.  Good password policies will get rid of the special character requirements in favour of a mandatory minimum password length and a randomness checker.  Strictly speaking, the best passwords are long and hard to predict.  It doesn't matter what kinds of special characters and numbers that they have in them.  You usually see mandatory maximum lengths of 16, sometimes 20 characters, but I encourage you if you can to ditch these entirely.  Longer is usually stronger. And mandatory minimum length is the best way to get people to generate strong ones.  And tell your clients about Diceware passwords, by which I mean passwords made up of four or more random words,  which are easy for humans to remember in a sequence, but hard for computers to guess.  One of the slides here is an example of one that I generated last week.  This is a 40 character password. It isn't a predictable sentence. It's not a quote from Shakespeare or something like that.  But it is definitely something that I could memorise if I really had to.  Please make sure that your password policies support passwords that look like this one.  And don't reject it as weak, because there are no symbols or numbers in it.  Some password managers will generate passwords that look like this,  but if you don't have that option and you need to come up with one for yourself,  I like to think of something that was on the shelf in my bedroom when I was a kid, you know, a sequence of things in the order that I remember them.  Or people suggest making up stories about the sequence of words to help you remember all of these sorts of things.  Pretty much anything that is a sequence that only you could think of.  If you can get it generated by a machine, that's probably the best way to do it.  But good password policies are meaningless if you don't bring your users along for the ride.  And using diceware passwords is also pretty meaningless if you don't use a password manager to record them,  because even though they're long and easier for humans to remember, they're still really annoying,  and we still have so many accounts in our day-to-day lives that people will fall into that old trap of just repeating them over and over again.  And someone's unhashed, unsalted database will get leaked, it's inevitable, and that password will become public.  So here's point 4A, which is education.  For any of this to be really effective, you need to educate people about good password hygiene,  and tell them about password managers.  And by this, I don't mean just your users specifically, but also your friends and your family,  because good password practice goes way outside the scope of your work project.  This is a long-term, real-life, meat-space effort.  Please gift people subscriptions or link them key pass, key pass X, teach people how to use password managers  so that we can write password policies that generate strong passwords.  I think a password manager has kind of a band-aid on the whole problem of passwords.  They don't really solve the fact that we have way too many passwords to deal with on a day-to-day basis,  but as the name suggests, they do make passwords easier to manage.  Long strings like the ones I'm recommending are not so easy to handle without them.  There's last pass and one password and key pass and dash lane and many.  All of them have their strengths and their weaknesses, but using any one of them is better than using none at all.  So get out there and start showing people how to use them.  Back within the scope of your work project, a quick and easy way to educate your users about strong passwords  is to give them automatic client-side feedback on the passwords that they give you  when you're signing up and account with them or when they're changing.  Dropbox came up with a really great tool called ZXCVBM,  which gives instant feedback to your users on the strengths of the passwords that they're trying to give you.  And it determines strengths on how long a string would take to break in terms of time,  rather than what kinds of uppercase letters and lowercase letters and symbols that it uses.  It also contains a really good dictionary of common words and leaked passwords to help people avoid those.  And it's been ported to Python and a lot of other languages, so go and try that out.  Point five, rethink the idea of working on systems that are using biometrics as the only form of authentication.  This is the medium-length form of a particular rant of mine,  but the basic thrust of it is that if your password gets compromised, you can change it.  If your fingerprints get compromised, it is very hard to grow new fingers.  And when I say compromised, biometrics can be compromised in many more ways than a straight-up password can.  Passwords get leaked in database dumps and on post-it notes,  or actually my Uber driver told me hers on the way back from the airport.  But we keep coming up with new ways to steal and fake biometric information all the time.  Late last year, Adobe released a new piece of software called Voco,  which can generate samples of a human voice after being fed about 20 minutes of speaking data.  So when I don't have an epic cold, I'm someone who narrates audio books in my spare time.  So I can really appreciate the idea of not needing to be called back to the studio to do an extra 10 minutes of recording.  But I am also someone who works really closely with authentication software,  and I can see the potential for someone to get one of my recordings,  even the recording of this talk, and feed it to Voco,  and then have it rattle off the passphrase for my phone banking account.  And for anyone thinking of doing this, you won't be able to do this with that service,  or with any other service I use, please do not try.  But if you have ever given a conference talk or appeared in a recording,  be aware of what is becoming possible.  Don't enroll yourself in this stuff, and don't build it into your systems.  And there's more good news for a given value of good.  In January, some researchers in Japan discovered that the average smartphone camera  can capture detailed images of somebody's fingerprints from three metres away,  if the lighting is really good.  And this means that you can get fingerprint information from any Facebook selfie where you throw up a peace sign,  or you can steal a fingerprint pattern of a public figure if they were photographed close enough and they weren't wearing gloves.  Not unrelated, a lot of recent breakthroughs in 3D printing and medical technology  mean that we are getting better at printing human skin,  which is great news for a lot of people,  but it also means that all of that Gadagastyle biometric fakery just got real.  But digital stealing and faking is the softer approach.  In 2005, an accountant in Malaysia parted company with one of his fingertips.  After the people who stole his Mercedes from him at gunpoint  realised that they needed his fingerprint to start it.  Slightly less violently, there was the story of the six-year-old girl in Arkansas  who used her mother's fingerprint while she was asleep to unlock her iPhone  and rack up about $250 worth of Pokemon toys.  Bimetrical looks really cool in the movies,  but the movies are also where people end up with their eyeballs being removed to bypass it.  And look, I mean, there's a lot of really cool stuff about living in the future,  but I don't want to bring this part into it.  So, if you're working on a project that is thinking about it,  see if there's something else there that might fit that need instead.  And if you must use biometrics,  make sure that they are only one part of several factors needed to authenticate  because they're very easy to hack both technologically and socially.  Six-year-olds can do it.  So to recap, salt and hash, implement MFA,  support U2F, enable more than one MFA,  write proper password policies and educate people about passwords,  and say no to standalone biometrics.  And here's that link again to my notes and my resources  in case you want to take a picture and look it up later.  And I'll tweet it just in case.  I know that these are only really small things,  and this seems like really basic stuff,  and this stuff won't make the world perfect,  and they won't make people completely unhackable,  but they'll make the state of things a tiny bit better than the way that it was.  I would love a happy ending to the story of passwords,  so please help me write one.  Thank you.
hunter2_0_131.png hunter2_132_251.png hunter2_252_359.png hunter2_360_1427.png hunter2_1428_1475.png hunter2_1476_2699.png hunter2_2700_3371.png hunter2_3372_4031.png hunter2_4032_4283.png hunter2_4284_6563.png hunter2_6564_6911.png hunter2_6912_7295.png hunter2_7296_7535.png hunter2_7536_7859.png hunter2_7860_8819.png hunter2_8820_9383.png hunter2_9384_9791.png hunter2_9792_11135.png hunter2_11136_13067.png hunter2_13068_14591.png hunter2_14592_15995.png hunter2_15996_16211.png hunter2_16212_17435.png hunter2_17436_18167.png hunter2_18168_18743.png hunter2_18744_21191.png hunter2_21192_25823.png hunter2_25824_28379.png hunter2_28380_29915.png hunter2_29916_32903.png hunter2_32904_33419.png hunter2_33420_34427.png hunter2_34428_36059.png hunter2_36060_37763.png hunter2_37764_38699.png hunter2_38700_39875.png hunter2_39876_40583.png hunter2_40584_42479.png hunter2_42480_43523.png hunter2_43524_45071.png hunter2_45072_45503.png hunter2_45504_45791.png hunter2_45792_46331.png hunter2_46332_46451.png hunter2_46452_46619.png hunter2_46620_46646.png