hunter2: A Symphony of Password Horror by Lilly Ryan

Um feel free to wave out if it's if the audio quality is not great. Um 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. Um also 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. No, these don't. Oh my gosh. What happened to the dead bananas? Hang on. Think we have a loose banana? No, loose bananas. There's no good. Oh well, we'll see how we go. Um anyway. Oh I know where they're not working Now they're working.

Okay, cool. Alright. Problem solved. The bananas are functional. Alrighty. So this is uh this my Twitter handle in case you want to be friends on the internet. Um all right. Uh 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 was the first vampire movie 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. Uh secondly, because most password policies are about as well written as Twilight.

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 mention and I've put it 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 of 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 cybers are 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 one, two, three, four, five, six. 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 lot 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 is still the most common way to quote unquote get hacked. Restrictive password policies mean that people make poor password choices and they repeat their password.

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 that 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 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'd stolen. There was no two-factor authentication on this cave. One day, a guy called Alibaba 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, Alibaba 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 Alibaba and the Forty 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 An America 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 to be 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 was 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 role So MIT decided what most parents decide, which is the sharing's 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 his 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 plaintext 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 MR. 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 Aeneas 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 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 their database like a semicolon.

And passwords which use characters or fancy accented parts or characters with fancy umlets or accented parts or uh God forbid, emoji, are very bad passwords who will be sent to bed without dessert. Or the ability to pay your bills. I use 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 all this whole situation is kind of awkward. Most of the time. But we know that we can do better. We enable multi-factor authentication on all of our accounts. And 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. Firstly, salt 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 will The PhD student islands of the world will do whatever they've been doing since the 1960s. So we need to add some salt. Salt 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 salt on all the passwords in your system. And maybe keep it to yourself. Don't publish this anywhere particularly important. important. Then before you store it, you run the password and the salt together through a hashing algorithm, get the output of that algorithm, maybe run it again a few times 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 SHA1 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 insult 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 salt that you used for each password and how many times you went around, which makes the task

approximately infinity times more difficult. And look, I mean 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 of 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 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 Argon2. or Bcrypt 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 look login. 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 Axes has you covered there.

According to their docs, they're called Axes because, partly because Axis sounds like access. And also because accesses are 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 you work on that you can. Passwords alone are not enough anymore. Multifactor authentication means that we need a password, aka something we know, and another piece of information aka

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 YubiKey, that speaks directly to your browser and uses public public key cryptography to uniquely identify you when you try to log into your account. It also requires you to touch the keypad on at once, much like a banana , to prove that there's a live human at the other end 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 up going on under the hood of that.

So if you want to learn more there's a link to the YubiKey white paper in my notes or come and find me afterwards because I really enjoy talking about UbiKey. 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 that 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 in some instances. officially. So avoid SMS if you can. But multi-factor authentication for Django is really easy, which is great. Marcus Holteman 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 2 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 a 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 superusers like me. There have been heaps of headlines over the last few years about how this or that technology has gone 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 Tweedell 's PyCon Australia uh 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 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 lengths, mandatory minimum lengths 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 series.

Sequence, but hard for computers to guess. What I've got on the slides here is an example of one that I generated last week. This is a 40-character password that isn't predictable, 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 memorize 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, sequence of passwords. 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 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 right 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, unsorted database will get leaked, it's inevitable, and that password will become public. So here's point four A, 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. Teach people how to use password managers so that we can write password policies. generate strong passwords. I think a password managers as kind of a band-aid on the whole problem of password. 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 dashlane 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 an account with them or when they're changing. Dropbox came up with a really great tool called ZXCVBM, which gives instant feedback to their user to your users on the strength of the passwords that they're trying to give you.

view. And it gives it determines strength 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 um 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 or th biometric information all the time. Late last year, Adobe released a new piece of software. 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 a an epic cold, um I'm someone who narrates audiobooks 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 ten 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 Voko, 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 get can capture detailed images of somebody's fingerprints from three meters Away if the lighting is really good. And this means that you can get fingerprint information from any Facebook selfie where you threw 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 unrelatedly, 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 Gattaga style biometric figurage Got real. But digital stealing and faking is the softer approach. In 2005, an accountant in Malaysia parted company with one of his fingers fingertips, after the people who stole his Mercedes from him at gunpoint realized 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 a sleep to unlock her iPhone and rack up about $250 worth of Pokemon toys. Bimetric Oath

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.