How NOT to Store Passwords! - Computerphile
ฝัง
- เผยแพร่เมื่อ 19 พ.ย. 2013
- Security of users' passwords should be at the forefront of every web developer's mind. Tom takes us through the insecure ways in which some websites deal with passwords.
Note: At circa 8mins, the animation does not show how the 'salt' is also stored in the database alongside the username.
Hashing Algorithms and Security: • Hashing Algorithms and...
Security of Data on Disk: • Security of Data on Di...
More from Tom Scott: / enyay and / tomscott
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: bit.ly/bradychannels
"You might be watching this years in the future"
Just remember that nothing you can code is secure against the xkcd approach to password cracking - you find the user and beat it out of them.
IVIaskerade I don't actually know some of my passwords (I only remember how to move my fingers to write them). So that makes it a little harder unless there is a keyboard nearby :)
IVIaskerade They don't call it 'rubber-hose cryptanalysis' for nothing...
frtard I know that, Bahahaha that tactic is just too funny. Lol, I'm not |\/|askerade, by the way XD
Thanks for the advise! I changed my youtube password from 12345 to 54321!
***** should we try logging in as you then?
chillin chum Please don't! You will see all my private videos detailing all my privater information. Like how my name is Jesse Parker and I live in Canada, Alberta.
***** I don't know if your being serious, but if you are, sorry, I'm only joking. XP maybe I should have made that more clear, oops.
+Catlord just subscribed bro :-)
Always put salt on your hashbrowns.
Once I played a game years ago, forgot my password in about 2 months so I clicked Forgotten password? And it told me to put in my old password.
When aliens attack the Earth and we are all doomed, I want the world leaders to choose this guy to go on TV and explain to everyone why we are screwed.
The first time a website emailed my password back to me with no security, I was astounded. Thanks for a glimpse behind the curtain, to understand the stupidity of people who design web systems.
I am watching this years in the future, how did he know?
just have your password 'incorrect' so if you get it wrong it will say " your password is incorrect" and then you will remember
Something else important: The vast majority of hashing algorithms are VERY FAST! They've been designed that way to make document signing easy. So in addition to salting, you also generally want to repeat the hash recursively, for a few thousand rounds, or generally whatever takes 1/10 - 1/4 of a second. The longer you can make it take, the longer it will take an attacker to crack as well.
i hate that sites wont let me make a password that has more than 20 caracters and say i cannot use symbols
Shit, my password is "my_dogs_name"... Now I need to change again...
MidnightSlash. I changed for "safe_password".
boumbh Good idea, it's better than "unsafe_password".
strontiumXnitrate This one is actually not so bad...
Wow I didnt know youtube hides when you type your password. mine is ********** haha
man the time gap between comments when sorting by new is amazing
Shit, i just store my passwords in my HTML code!!
There's also 'pepper'. 'Salt' and 'Pepper'. Salt is a known random mutation string unique to the user, then the pepper is another unique mutation string unique to the database itself, but stored SEPARATE from that database, so that it is a secret to the database, with nothing linking the two together in any way.
ah geez, better change my password to password2 then
Ah, a couple things here could have been clearer in the infographics.
First, the database with the salted hash should have had *four* columns: user_number, user_name, salt, and salted_hash.
Second, the process of hashing a salted password isn't a complicated black box where you input the salt and the password and get out a salted hash. It's actually quite simple: if your password is my_dogs_name and your salt is m8jz6psqYc, then your salted password is my_dogs_namem8jz6psqYc. Just throw that into your hashing algorithm to get your salted hash.
Taiiwo Llort Yo dawg, I heard you like rainbow tables.
You wouldn't actually need a rainbow table of rainbow tables. Your rainbow table just needs to include every password with every possible salt attached to the end. Of course, since salts can be arbitrarily long and complex, that's impractical.
You are right that salting does nothing to make brute force attacks more difficult, but brute force attacks are already pretty difficult. Even if you have access to a password database, you could be spending a day per password with a brute force attack. With a rainbow table, on the other hand, you could get hundreds of thousands of passwords almost instantly.
Skrapion
Rainbow tables only make the creation of the tables easier by removing the need to generate random strings for each hash, and instead getting strings from previously created hashes.
You'd need a table where the first cell in each row would contain a random string of a given parameter set (length and character set). Within each cell would be salt, and a rainbow table with every hash using that salt. The next cell in that row would use an algorithm to generate another valid salt with the same parameters from the cell to it's left, this is really simple, but the more efficiently it can be done, the better. Each row would have different parameters for the salt, which would allow the user to search for a salt set with a given parameter set.
Reducing such a tiny computation in a project as large as this seems almost poinless, but combined with the benefits to search time make it a really efficient solution.
OK, please clarify that last method. You say at 7:45 about the salt "a new second password if you like that goes in the database". But if I understand this correctly, you're storing only the salt and the resulting hash, not the user's password, right? When a user logs back in, you take the password they provide and the stored salt and see if its hash matches the stored hash. Is that correct?
Websites that refuse to store their own passwords are actually a pet peeve of mine. I don't think you should do that. It forces people to link their account to another identity. Nothing wrong with offering the option, but it shouldn't be required.
Facebook is the worst, BTW, since the identity it links you to is usually your real life identity. And a major part of security online is being anonymous. So even if something does get cracked, it doesn't link directly to you in real life, allowing you the ability to create a new online identity.
the universal password solution... password123456
problem solved.
"You might be watching this years in the future"
Yeah 10 years later, hope this aged well.
safest place to store a password? a piece of paper under your pillow
6+ years in future. Video still being watched.
Nice video! One more addition: If you are implementing something like this today, try to use a hash algorithm that is not easily parallelizable (like MD5 or SHA-1 is) - graphics cards can crack these quite fast nowadays - and use one that supports a "rounds" parameter - basically a way to make a hash slower (and also make cracking it slower), so that it is possible to easily increase the password strength later when computers get faster, without hogging up your server today for 5 seconds whenever someone logs in. Good choices (as of end of 2013) are PBKDF or BCrypt.
And if you increase the security of an existing website by replacing unsalted (or just SHA-1 salted) hashes with more secure ones, re-hash any old passwords you find when the user logs in (and not only when he changes his password), because at that time you have the cleartext password and can re-hash it. Lots of people will not change their password often and that will put their passwords at higher risk if they are still stored in a more insecure hashed format.
1,23,4,5,6
that's the worst password ever that sounds like what an idiot would have on his luggage!
watched this while eating food. Usually I watch small funny episodes.
Plan to watch these video every day while eating something. Knowledge is power
5:08 do i hear a kitty?
7:54 but then how can you compare the salted password when the user wants to login or something??
You know a nerd by his emotionality towards topics most people don't even understand on a basic level.
Mmm, salted hash... I should probably take a break from the internet and eat if this video made me hungry...
Two other important additions: 1) hash password with salt first 2) apply a key stretching to an end user's password prior to sending up to the server. This ensures that even common passwords like "123456" take a long time computationally to crack instead of trying a quick pass over the database to discover all users with a "123456".
If I'm ever asked for my password, I'll just tell them "I, D, the number ten, T"
uhhh I'm watching it in the middle apocalypse of 2020.
It's 2022 and I just had to email this video to a large multinational corporation because when I clicked "Forgot my password" on their site, they emailed me back MY PASSWORD!
It's funny I was just watching this the other day, since news broke today that one of the major telecomunications companies in Iceland had been hacked into, and information about over 70 thousand people compromised (nearly 1/4 of Iceland's total population) and posted online. Not only had the company stored a massive amount of text messages unencrypted, but a huge number of passwords also, UNencrypted! Basicly the passwords in one column, names in the next, then email addresses, phone numbers, social security numbers etc. And this is one of major corporations in Iceland, totally unencrypted ... only two minuted into this video and they would have realised their stupidity ...
The current standard (2013-14. May even be outdated now?) is to use Bcrypt. Why?
MD5 and SHA1 take milliseconds to create a hash, while Bcrypt allows you to set the time complexity. For example you can set Bcrypt to create a password in 0.5s. Assuming md5 can hash 1,000,000 per second, and Bcrypt 2 per second, you've now HUGELY slowed down any attempt to brute force your passwords.
Dear ComputerPhile, thank you for finding people like this guy who can explain stuffs so well and make you want to learn even more. I don't know much about web security, but with the past videos on the subject, and with this remarkable guy, things are getting clear.
If not already one, he would be a great teacher.
So thank you again for making this video!
I really don't want to sign in with Facebook or Google etc, they are privacy nightmares and it is none of their business what webpages I am signing in to (yes I block Google analytics etc).
Somebody should show this video to the folks at Sony...
"And if Ive just said either of your TH-cam passwords go change it." Made me laugh way too hard.
"You might be watching this year's in the future"-
Me watching 10 years later..... Yes
I loved the energy of this guy, the spirit of the video, and the explanation. The way he said "You might be watching this years in the future" I liked it (:
In my country there's a debate going on about internet voting in general, and it's seriously considered. Estonia has implemented e-voting and electronic government and is always used as an example of "successful" e-voting system. I've read a bunch of articles proclaiming hashing (alone) as an "unbreakable" way of encrypting data. I'm glad I can see that video too, and compare.
I still think this is one of the best videos to ever be published by Computerphile.
Hey Brady, I'm glad you put links to the extra videos at the end in the description, since you can't click the ones inside the video frame on a phone.
Keep doing that!
If the salt is random then there would be no way to compare the two passwords unless the salt is also stored. Isn't stealing all the users passwords and salts the same as stealing their passwords and secret questions then?
Well this episode was fairly entertaining, especially as it has a connection to an event right at the moment of time.
Really really cool, 10/10 want more of that.
0:58 "you may be watching this years in the future" yeah I am lol
I don't even know why I'm subbed to this channel, I know nothing about computers and I never really grasp what they are talking about on any significant level.
The important thing to note for salted passwords is that the same salt has to be used to verify a password. The current standard is using a keyed hashing algorithm with per-password salt. You have to store the salt so that the same salt can be added to an entered password to compare it to the stored (salted) hash.
The salt's purpose is to make it harder for an attacker to work backwards from the (salted) hash to the password--it does nothing to prevent random password guessing.
Other things that you can do are using other pieces of information (ip address, google authenticator, a code texted to a phone, etc.) as something in addition to the password for logins.
from future
still this holds true
There should also be a mention of key stretching. By re-applying the salt and re-encrypting the hash a large number of times, it becomes linearly more computationally difficult to brute force a collection of password hashes. You can require 1000+ times more computational work per single password attempt. Of course, this means every log-in from a user would also require 1000+ times more work to authenticate.
Computerphile is by far one of my favourite TH-cam channels!
Keep up the god work!
'You may be watching this *years* in the future.'
_Chokes on tea_
No way!
I'm now "years into the future" - how amazing!
It's a big pity that it wasn't explained more in-depth how salting works. Like how you can used your salted hash to verify someones password.
I looked it up, and the solution is that the salt is also stored in the database and added to the typed-in password every time a login is tried.
So at 8:18 it should have shown an extra field; That of the salt.
Actually, you can store the salt in the same field as your hash. And you also define the hashing function in the hash too. It's a standard format used on Unixes specifically designed to be future proof. It looks like $$$$$
cyphardotcom Thanks for the insight!
Amazing video.
In my opinion, this is the best Computerphile presentor yet.... He is so passionate it's watching :)
I would like to see more videos from this person. I've watched every video of this channel with him talking and they are all very fascinating. Please give us more!
I've had websites email me my password when I asked for it...
Important note is that you should use salt + some hashing algorithm that takes relatively long to encrypt that password string. Like 1 second long. This way, even brute force attack will take, as you said, forever. But using hashing algorithm like MD5 that takes less than 0,001 s is no problem for brute force, since you can try all the combinations for 6 letter password in like 40 seconds.
I love all the videos with this guy. He's so passionate about it
dayum 9 years and its still so useful
How could i not watch this video in the future? xD
Ok, but how do you compare the password once you've added this huge random string to it?
I really like watching Computerphile videos with Tom Scott
This guy is awesome! The way he explains things is really good! I hope we'll see him more often :)
"years in the future" - i guess he was right
This is like saying: "Its hard so don't even try". Actually, you actually DO say that (00:24).
So by that logic, we shouldn't even be programming. Or driving cars. Or playing sports. Or being alive.
Indeed, I say the opposite - TRY. Just learn before you do. It's not even hard to set up secure password storage, if you know how to read, because google returns (approx) 71,500,000 results when you type in "secure password storage".
Of course, knowing anything whatsoever about secure application design, firewalls, encryption, and other super basic internet security concepts is a must. Skilled surgeons are skilled surgeons because they paid attention. Same applies to everything else in life.
i am looking at it after 5 years of upload
Okay, absolutely brilliant ;) Once again you show class Tom, altho I always preferred adding the encryption layer over the salthash layer whenever I could.
Looking forward for more!
There's a mistake at the beginning - you can't actually tell if a website stores your password in plain text in db just because they offer to send it to you on demand. It could very well be encoded with a two-way algorithm.
Now, I'm not saying it's a good idea, but it doesn't mean it's there in db in plain text - you can't actually tell. (One could argue that it's almost as if it was in plain text - because if someone grabs your source code and db, they will be able to decipher passwords)
I'm watching this years in the future!
Glad to know that the Hash and Salt method is still considered pretty good practice. Many webshops and forum systems use it.
I once took part in a website design and programming competition for high-school kids, where part of the judges rubric was security. I went on to win 2nd place, but the method I used to secure my site was much stronger than what all the other contestants offered.
The method I used was to store the time a user signed up as en epoch date, along with their username (which was less-extensively hashed) and soon-to-be-hashed password. I then used that epoch time as a seed in a psuedo-random number generator that I modified for custom results, created a random 16-character string from that generator using the seed, then used that string as the salt. The hash algorithm I used is a 256bit SHA-2 hash.
For the username, I simply hashed it with the epoch itself. I didn't want to worry too much about the usernames, but wanted just enough security so that an intruder doesn't know both the username or password, only the epoch time they signed up at. I'm not sure how secure that method in general is, but I feel the whole method overall was overkill, though it works.
I also like the method I used more than some alternatives, because you aren't storing the salt, rather a value used to make the salt. I had another layer of security to combat knowing the algorithm itself used to make the salt and hash the password. That next layer is what I describe in the next two paragraphs, and you don't have to read it as it isn't exactly related to the video.
The epoch-to-salt generator and password-hashing is compiled code that the web-server program I used would run during each login. The code itself was as secure as I could make it as well. It has warnings checked, so that they can't use warnings to figure out parts of the code. I stripped all tables and used no strings, so they can't visually and easily identify parts of the code. I also added dead-end and false-alarm code, so that reading the instructions of the reverse engineered code will give stray as well as real instructions.
That way, even if they managed to access the code behind my web-server as well as the database, they would still have to figure out how to decompile, reverse engineer, and read the instructions of the code itself. I know from experience with decrypting and reading the instruction sets of iOS apps that it isn't too difficult for a dedicated person to do just that, but it still adds to the tasks and difficulty that many hackers wouldn't deal with (on a very un-related note, I like to hack, hook onto, and inject my own code into iOS apps, so that I can add new features to games and apps myself).
In all, the only way for a hacker to have figured out the passwords from users was to either go through the steps to reverse engineer the code, brute-force the hash algorithm, or monitor what the user types in the password box using a program on their computer. The reverse engineering option is way out of the picture, as that would require bypassing other security layers to retrieve the code in the first place, as well as the added security padding I put in the code. Brute-forcing the hash algorithm would take an immensely long time for a computer to do, and hardly any look-up tables exist for 256-bit SHA-2, especially extensive enough to figure out the salted passwords. Last, programs on someones computer that monitor the passwords they use aren't really the fault of my website, and anyone using any website is susceptible to programs like that.
So you saying I should change my youtube password from 123456 to 1234567? :P
i store passwords in .txt file on server. That good?
Love Tom's videos on this channel!
this is cool,you learn so many things by these guys,keep up the good work.
This guy is a great educator.
And this is why the most secure sites have added 2- or 3-step authentication. Not a guarantee, but an added layer of protection if your password is grabbed from their site or any other!
On the other hand, annoying as hell for the user.
True - it's unfortunate that the higher the level of security, the more complicated it is for the end user. In the end, it comes down to a balance between the two.
Depends on the implemented factor'd authentication. A text message to a cell phone is great as long as you have your cell phone. The "image and question" method that banks use has been proven to be what is called "security theater". It makes the user feel secure, but is actually useless.
As well, 2 factor authentication isn't going to save your password when the database is stolen. It just means that if you chose 'password' as your password and someone stole it, they couldn't login to THAT service. But they could potentially login to your email if you use the same password.
Best practice is to choose a separate password for every service you use. Generate it randomly as secure as possible (mix of letters, numbers, symbols and case). Generate it as long as possible to prevent bruteforce. Store this password securely (either using something like keypass or a service like LastPass - just enable 2 factor authentication for the service and choose a REALLY secure password) and backup to a secured drive or image (Truecrypt is great). Nice thing about the Truecrypt image is you can put it in the 'cloud' (as well as local) and get a little more safety.
If someone steals your password from insecuresite.com, you'll love this in the long run. Just last week I got an email stating a site needed me to reset my password and I just thought "okay, glad I dont have to reset all of them".
Indeed. The simple fact of the matter is that there will always be a trade off between security and convenience. Ideally you would enter your username and password manually each and every time you visit any site, as well as entering a unique code sent to your phone-or some other 2nd-factor authenticator-every time. But that becomes a pain on a regular basis, so people don't want to do it.
Tom Scott is really great, wish we'll see him in more videos in the future Brady! :)
Thank you sir , I am just working on a project and I would do the research probably finding out myself but you explained it perfectly and direction saving me a lot of time. Really like to watch your channel.
He says we know people use method 1 because they send the plaintext password to the user on requestio, but that happens with encryption too. (However, I suspect that many are using plaintext.)
Anyway, his answer isn't quite good enough. Make sure your hash is intentionally slow. We can calculate 200 000 000 MD5sums (which is also partially broken) per second with a good consumer computer. If you use iterated bcrypt, it takes, well, depends on the interations, but if it takes a second, logging in now takes an extra second of server time, but cracking a password takes 1 second * the number of attempts. So don't just use salt and a secure hash. Use salt and SLOW hash. (Probably bcrypt.)
Also, if you do avoid doing this on your own and integrate Google and Facebook logins, please use Persona or something similarly decentralized. I give all my data to Google, but not everyone wants to, and they (and I) probably shouldn't.
Thanks for the two tips man, especially the slow hash one. Also, adding pepper to the slow salted hash would make things better :p
***** Making a slow hash is great if you have an array of servers with decent computational power, but you can basically achieve the same effect by waiting 3 seconds before you validate the password and return the network response. This is assuming you're not worried that anyone is going to hack into your database, which if you're a small operation that doesn't have a lot of servers and doesn't have a lot of internal people looking at your database, you can pretty much guarantee this.
Scott Gartner
I don't think you understand. If it takes a split second to guess at a password, brute force attempts become feasible. Brute force is pretty much the only method hackers use. If you increase the time between attempts to a couple seconds, it will take lifetimes to guess the password.
Scott Gartner How would brute force (meaning generating all the passwords and trying them out probably using some backtracking algorithm) work on websites that block the account after a given number of consecutive fails... let's say 5? Let's say my password was 123456... then the backtracking would try 123451, 123452, 123453, 123454,123455 and then it gets blocked just before trying 123456 which is actually the password. It wouldn't even get to 123451, because it would start with 111111 then 111112 and so on. It would probably get blocked after 111115. Of course this is an extreme example and not all backtracking algorithms necessarily generate stuff in alphabetical order... but I trust you get the point. If you limit the number of consecutive fails, brute force becomes useless.
DarthGhitza The assumption throughout this conversation is that the bad guy has been able to get a copy of your database. The methods we are talking about are intended to be used directly against the database, not via a web application. In fact, the bad guy might get the source code to the application as well, but if the algorithm is truly secure that won't afford him any significant benefit in cracking passwords.
Question about salt: seeing as every username will have its own random salt, the salt must be stored somewhere as well. How is it that, even if someone manages to get the salted hash and the user's salt that they're unable to reconcile the two in order to find the original password string? I'm sure something about the way the salt and hashing algorithm work makes it impossible to deconstruct, but I have little idea as to the mechanics behind it.
00:55 Yep, watching it "years in the future"
My favorite computerphiler
Interesting that the best approach is what UNIX /etc/passwd files have used since 1988 or 1990 (though with smaller salt).
Also interesting that the method used by repo.org.cz (first and only place I've seen it) which uses ssh keys wasn't mentioned at all. With this method, the password is assigned (or generated) to be a long random string (for security) but the user isn't required to remember it. Instead it is stored locally in a keychain, protected by a the user's local password.
Correct me if I'm wrong but a browser in a vanilla state doesn't have the capability to manage ssh keys on a keychain.
Megatherium
I wouldn't know.
However, I will say that I use a Mac, and the builtin Keychain Access integration with Safari is a pretty good substitute. It still alows users to pick bad passwords, but it's not scary to use a different (and 'strong') password on every website. The only thing nicer would be better (easier) auto creation of passwords. Also, I had to buy an app (which may not be neccessary anymore now that keychains can be stored in iCloud) to sync the passwords to my mobile device.
This makes me think of an even better (and in retrospect, glaringly obvious) system: the one-time passwords that my banks makes me use to access their sites. I have credit card sized hardware to generate them for one bank, and two different apps for access to the two others.
Most webbrowsers support client certificates, haven't seen hardly any site using them for authentification.
Yeah but what if the user loses their private key on their harddrive?
could you elaborate on this repo.org.cz method a bit more? Or perhaps point me to a tutorial?
It always frightens me that so many big names keep screwing this up. I knew about salted hashes and why you'd want to use them 15 years ago (at least). It also always annoys me that I get badgered to add punctuation and numbers and case changes to my passwords, when I already have a more secure procedure. But that's a rant for another day....
The best explanation on passwords I've ever seen. excellent
I had a great one from a Quality Inn website - not only did it store my password in plain text, but it helpfully displayed it on the screen in my profile when I logged in!
"Nowadays" is highly misleading. Hashing+salting was used to store passwords in most Unix systems since at least the 80's (probably even the 70's). It's not a new technique used "nowadays".
Using Facebook, Google+, Microsoft, etc instead...? Those are all hacked with NSA backdoors. If you rely on that service, you guarantee your application will be hacked. You're also giving a third-party the right to create/control admin accounts on your system.
Fantastic. Already seen this many many times, because it's so easy to understand and kind of funny
My god this personalized content thing is going really far, that guy even knew all of my passwords.
When a user tries to get into their account with a salted hash system, how does it compared the entered password with the salted and hashed password stored in memory?
And if this stuff is interesting, listen to the Security Now podcast with Steve Gibson. He talks every week about the Adobe flubs and the NSA spying, etc. and explains this type of thing also, and many other fun topics.
One of the best videos I've seen on this channel.
Wow that timing, the dating site "Cupid Media" just got hacked, and exposed 42 million unencrypted ( plaintext ) passwords. Great video as always, especially with Tom.
I don't even know my own passwords - hope nobody else does either.