Hi, my name is Bret McGowen and I'm a software
developer here at Rackspace and I work on the RackConnect project. So today we're going to talk a little bit
about password security. You may have seen in the news over the past
few months and years some companies that have got into trouble because of their password
security, so we're going to talk for your app what is a good approach to take. So a couple of things to note, a lot of people
want to put encryption on their passwords, and so we'll talk a little bit about what
is the difference between encryption and hashing your passwords and why encryption is probably
a bad idea so lets kind of talk conceptually what the difference is. So for encryption, that is like a safe, right. So here is your safe, and if you know the
password and you know the combination, you can get into that safe. So that is where you want to put something
like credit card information, potentially, stuff that you have to read back out as-is. Now we are going to talk about hashing. Now hashing is a little bit different in that
is what we call a one-way function. So the analogy that I've heard that I kind
of like it's like if you put a cow through a machine and you get a hamburger. Right. You cannot put that hamburger back into that
cow. And if you had the perfect machine, every
time you put the same cow through you'd get the same hamburger. So that's kind of what hashing is like, it
sort of fingerprints your password. But from your fingerprint you can't recreate
the original password, so even if a hacker gets your database, just by looking at the
hash or the password, they can't actually get the password out of it. So the idea there is when someone logs in,
what you do is you actually take their password, you run it through the hash, you get their
hash value, you compare what is in the database and if those two values match then you know
the password is good. So that's how you can compare their password
and check it without actually knowing what their password is, without saving it anywhere. So that brings up a little bit of another
issue though, which is if a hacker gets your database and has a list of all hashed passwords
in there, there are a couple of tricks that they've figured out. One of these is called rainbow tables, or
pre-computing tables, and what they'll do is they will actually take all the words in
the dictionary, all the words from one letter all the way up to twelve letters, sixteen
letters, and they will take common hashes so MD5 or SHA1 and they will pre hash all
the possible combinations of passwords that exist. So then what they do is that they look in
their huge mega-list and then they look through your hashed password value in the database,
and if they find a match then they know what the password is. So, to get around that, to make it so that
hackers can't do that, we'll introduce something called a salt. And essentially all a salt is, is that is
going to be a random sequence of characters. So let's say like 128 characters, and when
the user creates their password, we'll just randomly create a 128-character string. Then you'll take the salt, attach the password
to it, and you will hash this whole string. So now you actually have (A.) a much, a much
longer password and then you'll take this password and add the salt just in plain text
(and usually with some kind of delimiter, so, like a colon) and then you'll add that
to the hash. So in the database it'll say salt, colon and
then the hashed salt plus password value. So now, because you have a different salt
for every user in the database, a hacker can't pre-compute what all those values will be
and so that's pretty much a good way to ensure that, if a hacker gets a database that they
can't know your passwords. If they kept at it long enough, maybe, maybe
they could get one user's password, but they are not going to compromise the entire database. So an important thing to know here though,
this salt needs to be unique per user, because if you had the same salt for every password
in the database, if the hacker gets their hands on that salt, it's the same as if they're
getting the encryption key to the safe, which means they can unlock all the passwords in
the database. So that in a nutshell is hashing. If you're looking for a good hashing algorithm,
there are some out there, one in particular called Bcrypt that is recommended because
it's actually kind of a slow encryption algorithm and that's good because if a hacker is trying
to recreate the hash on your password, you actually want that to be really of slow because
it will take maybe you know a tiny bit extra when the user logs in, but they'll never notice
that. But for a hacker who is trying to do thousands
and millions and millions of hashes, it's going to take them a lot, lot longer. That's password security, thanks for watching,
I'm Bret McGowen; if you have any questions be sure to leave them in the comments and
I'll catch you next time.
Blink. Blink. Blink.
Besides that seemed fine. I like the conclusion. "Use bcrypt"
That's how I do it. 1 salt per user, randomly generated. The best advice is at the end though. Bcrypt is very strong because it's scallable. You can for it to take 1 second to hash a password, making a hacker's attempt to get to your passwords a nightmare.
Nothing breathtakingly new in this video, nothing wrong either.
Seems to me however that it is quite a clear explanation for people who have very limited pre-existing knowledge, so all in all: a really good video! :)
He mentions doing "salt + ':' + hash" Isn't that insecure? Wouldn't you want to try and make it difficult by placing those in another area such as a different table with a related UID or something?