Hunter2: A Symphony of Password Horror
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 17 | |
| Number of Parts | 48 | |
| Author | ||
| Contributors | ||
| License | 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 | |
| Identifiers | 10.5446/33193 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DjangoCon US 201717 / 48
2
5
6
14
16
23
26
30
31
32
34
39
43
48
00:00
PasswordPasswordMultiplication signLatent heatCASE <Informatik>DatabaseSingle-precision floating-point formatAuthenticationLink (knot theory)Operator (mathematics)1 (number)LeakTouchscreenFunctional (mathematics)WebsiteAxiom of choiceGoodness of fitMassProcess (computing)WordPoint (geometry)Task (computing)InternetworkingCombinational logicSoftwareBlogVideo gameInformationSoftware developerAdditionMedical imagingForm (programming)Right angleService (economics)Message passingTraffic reportingNumberWave packetEmailMultiplicationSoftware crackingSlide ruleCybersexTwitterShared memoryHacker (term)Meeting/Interview
04:36
PasswordDigital photographyFamily1 (number)Software testingAuthenticationOpen setElectronic mailing listSeries (mathematics)Multiplication signImplementationSystem administratorDifferent (Kate Ryan album)Flow separationAdditionCodeTwitterAntivirus softwareInformation technology consultingEvent horizonScaling (geometry)Computer animation
07:25
PasswordString (computer science)Student's t-testMultiplication signComputer filePhysical systemNuclear spaceDecision theoryMereologyBlock (periodic table)InternetworkingFlow separationNeuroinformatikGame controllerUniverse (mathematics)Shared memoryExterior algebraInheritance (object-oriented programming)Point (geometry)Message passingCodeDisk read-and-write headCodeLoginPanel painting
10:48
PasswordDatabaseSign (mathematics)Physical systemLoginMereologyControl flowNumberCASE <Informatik>Computer animation
11:29
PasswordMultiplication signInformation securityPoint (geometry)Computer animationLecture/Conference
12:06
WordPhysical systemArithmetic meanService (economics)Memory managementWebsiteComputer configurationNumberDefault (computer science)PasswordHash functionPublic-key cryptographyPoint (geometry)Data storage deviceAuthenticationMobile appAuthorizationInternetworkingRandomizationImplementationLink (knot theory)Function (mathematics)CASE <Informatik>Student's t-testAlgorithmMathematicsRoundness (object)DatabaseKey (cryptography)PermutationMultiplication signClient (computing)InfinityTask (computing)System administratorLoginHacker (term)Projective planeTouch typingDivisorRoboticsDifferent (Kate Ryan album)Web browserCombinational logic2 (number)Universe (mathematics)Configuration spaceToken ringSoftwareFacebookLengthData managementString (computer science)Instance (computer science)SimulationOpen sourceQuicksortContext awarenessResultantClosed setCommunications protocolTheoryGenderAverageMereologyPatch (Unix)CryptographyStandard deviationSystem callCountingCoefficient of determinationCuboidPredictabilityInformationVector spaceDigitizingPanel painting
21:19
Element (mathematics)Hash functionMaxima and minimaPasswordHash functionNumberData managementRandomizationCuboidBuildingFeedbackProjective planeLengthPosition operatorService (economics)SoftwareMultiplication signInformationSymbol tableCASE <Informatik>String (computer science)Term (mathematics)Sampling (statistics)Message passing1 (number)Physical systemFormal languageVulnerability (computing)MereologyWordSlide ruleData dictionaryGoodness of fitBiostatisticsSocial classOrder (biology)Roundness (object)Form (programming)SequenceAuthenticationComputer configurationMetric systemFingerprintData miningTournament (medieval)Virtual machineDevice driverQuicksortPattern languageDatabaseMedical imagingNeuroinformatikMotion captureSmartphoneAverageClient (computing)Process (computing)Identity managementFacebookLink (knot theory)Point (geometry)FamilyMetreInsertion lossPay televisionLetterpress printingReal numberVideo gameFigurate numberOnline helpRow (database)Information securityVector potentialSubject indexingHypermediaWritingArmRight angleDivisorFlow separationMatrix (mathematics)Proper mapAuthorizationTwitterCore dumpCAN busLoginVideoconferencingEntire functionPanel painting
30:32
BitState of matterPasswordPanel painting
30:58
Coma BerenicesXML
Transcript: English(auto-generated)
00:15
Feel free to wave out if the audio quality is not great. Okay. Thank you very much for coming along. I'm Lily.
00:24
What I'm about to share with you is a horror story about passwords. Also, a word 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?
00:45
Hang on. Do you think we have a loose banana? No? Loose bananas? This is no good. Oh, well. We'll see how we go. Anyway. Oh, I know why they're not working.
01:00
Okay. Cool. All right. Problem solved. The bananas are functional. All righty. So this is my Twitter handle, in case you want to be friends on the Internet. All right. 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,
01:22
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. Secondly, because most password policies are about as well written as Twilight.
01:49
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,
02:02
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,
02:20
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 these cybers are very scary.
02:41
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.
03:01
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,
03:25
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.
03:41
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.
04:05
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.
04:23
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,
04:40
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.
05:02
Passwords are a 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.
05:21
We are your IT folk and your testers and your system administrators. Sometimes we're consultants, sometimes we'll work in the 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.
05:41
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
06:02
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.
06:22
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.
06:40
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 had stolen.
07:01
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 thieves 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.
07:21
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
07:43
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
08:02
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
08:21
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.
08:43
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,
09:00
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 roller coaster tycoon. So MIT decided what most parents decide,
09:22
which is that 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.
09:42
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.
10:01
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.
10:23
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.
10:40
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 one uppercase and one lowercase letter, a number, and one special character,
11:00
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 umlauts or accented parts or, God forbid, emoji,
11:21
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.
11:43
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.
12:01
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,
12:23
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.
12:43
So here are some recommendations for five simple things that we can do as technical people to make this ever so slightly better.
13:01
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.
13:23
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 Ph.D. students of the...
13:40
The Ph.D. student alums of the world will do what they've been doing since the 1960s. So we need to add some salt. Salt in this case means a random string meaning 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
14:02
and maybe keep it to yourself. Don't publish this anywhere particularly 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, get the output of that, and then store that in your database. This example uses SHA-256 with only one round of hashing.
14:23
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 Ph.Ds.
14:42
Secondly, please don't use SHA-1 as your hashing algorithm because even though it was developed by people with mathematics Ph.Ds, it's a pretty old algorithm and insecure by today's standards. So if you hash and salt 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
15:03
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.
15:26
The good news is that if you're wondering how to do this and you 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,
15:41
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 infinity times longer than that for someone else to run all of the possible permutations of the salts and the hashes and the rounds,
16:02
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,
16:21
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 won't get to try very many times, and they won't get to hammer your service with failed requests.
16:43
Django access has you covered there. According to their docs, they're called access partly because access sounds like access and also because access are a thing that you can use to hack stuff, and they want to prevent hacking. And one more thing, while we're here,
17:01
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.
17:23
Multi-factor 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
17:40
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 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,
18:00
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 YubiKey white paper in my notes,
18:22
or come and find me afterwards, because I really enjoy talking about YubiKey. 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 that keyring full of RSA tokens that you used to have, which is pretty cool.
18:42
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,
19:00
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.
19:21
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
19:40
or get ahold 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. It has been deprecated by many people in lots of places, in some instances officially. So avoid SMS if you can. But multi-factor authentication for Django is really easy, which is great.
20:03
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
20:21
contains everything you need to implement, U2F, TOTP, a few other things, for your 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 the one-time password, plus a password itself,
20:41
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.
21:01
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 gonna be. Eventually, this means that one of these things doesn't necessarily need to be a traditional password.
21:22
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
21:40
to Fraser Tweedale'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,
22:01
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,
22:20
help your clients write their password policies. Good password policies will get rid of the special character requirements in favor 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.
22:40
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,
23:01
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. What I've got on 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 memorize
23:22
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
23:42
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,
24:00
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 dice-ware 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
24:22
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
24:41
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, meatspace effort. Please gift people subscriptions or link them KeyPass, KeyPassX.
25:03
Teach people how to use password managers so that we can write password policies that generate strong passwords. I think of password managers as 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,
25:21
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 LastPass and 1Password and KeyPass and Dashlane and many. All of them have their strengths and their weaknesses, but using any one of them
25:42
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.
26:02
Dropbox came up with a really great tool called ZXCVBN, which gives instant feedback to your users on the strength of the passwords that they're trying to give you, and 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.
26:22
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
26:41
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
27:01
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,
27:20
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 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 10 minutes of recording,
27:42
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 a 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,
28:01
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.
28:22
In January, some researchers in Japan discovered that the average smartphone camera 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
28:42
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 Gattaca-style biometric fakery just got real.
29:01
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 realized that they needed his fingerprint to start it. Slightly less violently, there was the story of the six-year-old girl in Arkansas
29:20
who used her mother's fingerprint while she was asleep to unlock her iPhone and rack up about $250 worth of Pokemon toys. Biometric auth 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,
29:40
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.
30:00
Six-year-olds can do it. So to recap, salt and hash, implement MFA to port U2F, enable more than one MFA, write proper password policies, and educate people about passwords, and say no to standalone biometrics.
30:20
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. 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,
30:42
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.