How NOT to Store Passwords! - Computerphile

the title this this video should be can we have this the turn this video should be how not to store passwords thank you um because you you really shouldn't store passwords yourself if you can all avoid it if you are running any kind of web service and and you are storing passwords it is so incredibly easy to get it wrong that basically you shouldn't try um if you can use sign in with Facebook or Twitter or Google and get them to handle it for you for crying out loud please do if you're a web programmer sooner or later you're gonna have to store passwords and this is this is the ways not to do it if you aren't other ways to do it I will kind of say that at the end but for please please please please look up a recent tutorial for the language you're using by the time you watch this video the advice will have changed you may be watching this years in the future look up a tutorial that's been written in the last few months by someone reputable and follow that how do you not store passwords the first instinct the naive thing [Music] he's just store the users password so let's say you have a sign-up box and you have a user name and password box the naive things that when the user signs up you take their password and you store it in the database as it is in plain text that has a couple of advantages first of all if they forget their password you could just email it to them and it means that you know checking it is really simple when they log in again you take their username you take their password and then you take what they've just typed you compare it to what's in the database and if it matches you let them in and that is the the naive approach to storing passwords there are still professional websites out there run by big corporations that still use this strategy and you can tell that using this strategy because they email your password back to you in plain text when you ask for it um this is a monumentally bad idea this is this is an astonishingly bad idea because if someone gets into your database through a security hole or because they're an insider with access and let's be honest if you're storing passwords this way you probably have other security holes too um then they can just read out every user and their password so you have their email address and you have their password and let's be honest most people reuse the same password for their email address on websites so this is a bad idea because it's incredibly insecure approach number two slightly that's naive still a bad idea if you take that password and you encrypt it so you you hide it behind something an encryption is two-way so encryption is something that you have a key that will lock something and then unlock it again so the naive approach is you take the user's password you take it into your database encrypted like this behind you know thing you've locked and then as Cheney's hand when they log in again you take what they've got you go here you unlock this you compare them and then you let them in now that's a little bit more secure because if someone just reads out the database you've got an encryption key there but it's got a couple of big floors first of all as soon as that Keys available the passwords still visible and can still be read out and it means that an insider or even a hacker in some cases can just take the encryption key as well with them and they've still got access to all the passwords that's a pretty bad idea the other floor with this is that if you have lots of people using the same password and if you've got a big site this will happen because lots of people will use one two three four five six or password one and if I just said either of your YouTube passwords go change it if you have that all the encryption will be the same so even if you don't have the encryption key you can still tell that all these people have the same password so it's probably a common one Adobe just made this mistake this month as we record this and don't be the big company behind Acrobat which makes PDFs behind Photoshop behind all the big tools millions and millions and millions of users their password database got breached gigabytes of passwords lost but it's fine they set yours yet mine was as well fortunately I didn't use that password anywhere else which is what you should hopefully be doing their passwords were encrypted and that was it it was just a you know a lock on it and it meant that everyone had the same password had the same encrypted code unfortunately also stored all the password hints with them which is which is wonderful because then you can look oh look there's 20 people who've used the same password here and that one says Michael Jackson is the password hint and that one says Halloween and that one says type of movie oh look it's Thriller okay wonderful it's Thriller and that's one of the biggest software companies in the world didn't do this properly um anyway so don't use encryption naive attempt number three hashing now I've talked about this in an earlier video um a hash is a summary of a load of data so let's say you have the password the user enters and you know that and when they enter it you're gonna hash it are you gonna put it through some kind of convolutions that ends up like that and then when the user enters their password again you takes it in the same way compare devastate which is great in theory but unfortunately if you open the same problem that Adobe hat which is that if you can tell a common password if it's in loads of people's database entries you probably can work out what it is worse than that as I've said before Google has an index of these things if you're using a basic hashing algorithm you can pretty much just type the code into Google and it will give you the password back as well as just searching for common hashes on Google there are these things called rainbow tables which trade off computation time for hard drive space so rather than having to calculate millions and millions of hashes for this one password someone has already done it for you calculated past but account allotted hashes for billions of common passwords and just put them out in a database it's gigabytes long but it's a lot easier to search through that than it is to try and do a load of calculation so if you're using something common like md5 or sha-1 with nothing else added the rainbow table will pretty much help you crack that in a few seconds I have in the past used all those nowyou've approaches myself on things I've built in my youth I've gone back and fixed them where they're still alive and just have quietly buried the code we're what they weren't but the approach nowadays is to use something called hashing and salting as I said the best thing is not to store passwords at all but if you have to the advice these days is hash salt so salt is a random string of characters that is different for every single user it's a password you know in your database in storage in plain text it doesn't matter the user could even know it not that it would help them with anything that means when the user registers they put the password in and it goes into the same algorithm but as well as that you generate a random string of characters for each user completely random a new second password if you'd like that goes in the database and that gets fed into this algorithm too so that comes in mutates it a bit more comes out with something else so if another user uses the same password that algorithm will get a completely different salt from them some people might based on the username that's generally a bad thing to do it should just be a random string of characters so the same password going in for a different user will mutate into something entirely different the point of this is that now you just have a random string for each user you cannot possibly pull the password back from this it won't appear in Google because it's a massively long random string you can't brute-force it back by looking at what common passwords are reused all you can do is do the old-style attack of trying every single common password one after the other and if your salts long enough and your hashing algorithm is complicated enough then that's really incredibly difficult to do do it right and it's lifetime of the universe difficult to do or at least it is until they use the password one two three four five six if you change one bite one bit anywhere in the file at the start of the middle at the end then the whole hash should be completely different this is something called the avalanche effect this very complex signal is not just dependent on the bit pattern that was last written to the drive but it actually depends on what was there previously

Channel: Computerphile

Views: 2,207,080

Keywords: computers, computerphile, Tom Scott, password, hashing, salting, hash and salt, database, web, internet

Id: 8ZtInClXe1Q

Length: 9min 24sec (564 seconds)

Published: Wed Nov 20 2013

Reddit Comments

[u/joolsburger]

Social sign up is a marketing tool, gigya and others use the info to personalise messaging and offers. I don't think it's really to do with passwords.

[u/frtox]

half this. half that making people sign up with a username/email and password is hard. a lot of people don't want to do it. if you already have an account no signup is necessary. helps registration numbers.

[u/malvoliosf]

Not even a little teeny, tiny bit true.

I have built a lot of websites in my life -- perhaps 5% of all Americans have used a site I have personally built. All of them safely stored passwords, and it isn't that hard. It's easy to do wrong, of course, but it is pretty simple to do right.

Many of the sites used delegated access (typicall OAuth) from Facebook or other large site, but it had nothing to do with my convenience. We just got much higher uptake when a prospective user can register with two clicks, lower error rates, and higher returns.

[u/hillkiwi]

This isn't even close to correct. Salting and hashing a password is incredibly easy - it's literally just a few lines of code and less than ten minutes of work.

Any developer that doesn't know how to do it doesn't have a chance in hell of implementing a Facebook login.

This video is aimed for people that are in their first week of learning (think 16 year olds).