How NOT to Store Passwords! – Computerphile

Posted on July 6, 2017 By

The title of this, ur, video should be, c…can we have this. The title of this video should be “How not to store passwords” um…uh, thank you, um because, y…you really shouldn’t store passwords yourself if you can at all avoid it if you are running any kind of web service and you are storing passwords it is so incredibly easy to get it wrong ur, that basically you shouldn’t try 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 web programmer sooner or later, you’re gonna have to store passwords and this is the ways not to do it if you wanna know the ways to do it i will kinda say that at the end but please please please look up a recent tutorial for the language you’re using.

um, 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 has been written the last few months by someone reputable and follow that. how do you not store passwords. the first instinct, the naive thing : is just store the users passwords so let’s say you have a signup box, and you have a username and password box the naive thing is when a user signs up, you take their password and 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 checking it is really simple: when they log in again, you take the username, you take that password, and then you check what they just typed you compare it to what it’s in the database and if it matches, you let them in and that is the naive approach to storing passwords and there are still professional websites, out there, run by big corporations that still use this strategy and you can tell that they’re 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 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 then, they can just read out every user, and their passwords so you have their email address, and you have their passwords 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 2 slightly less naive, still a bad idea is you take that password, and you encrypt it, so you hide it behind something and encryption is two way so encryption is so 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, encrypt it like this behind the other thing you’ve locked and then, 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 flaws first of all, as soon as that key is available the password is 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 flaw 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 123456 or password1 and if I’ve 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 Adobe, 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..

yours ? yes mine were 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 lock on it and it meant that everyone who had the same password had the same encrypted code unfortunately they’d also stored all the password hints with them 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’ OK, wonderful it’s “thriller’ and that’s one of the biggest software companies in the world didn’t do this properly anyway, so , don’t use encryption naive attempt number 3: hashing now i talked about this in an earlier video 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, when they enter it, you’re gonna hash it.

you’re gonna put it through some kind of convolutions that ends up like that and then, when the users enters their password again mutate in the same way, compare, they’re the same which is great in theory, but unfortunately you open the same problem that Adobe had 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 milions of hashes, for this one password, someone has already done it for you calculated 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 calculations so if you’re using something common like MD5 or SHA1 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 naive approaches myself on things i built in my youth i’ve gone back and fixed them where they’re still alive and just sort of quietly buried code where 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 a salt is a random string of characters that is different for every single user it’s a password you know, in your database, you can store it in plain text, it doesn’t matter the user could even know it, not it would help them with anything that means when the user registers, they put their 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 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 base it 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 from 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 wont 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 salt is 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 123456

As found on Youtube

Cyber Security     , , , , , , , , ,

. InterServer Web Hosting and VPS
InterServer Web Hosting and VPS
InterServer Web Hosting and VPS