Welcome to part II of our series on encryption and security.
We're going to get into practical issues now, and talk about how you can make sure your
experience on the Internet is as secure as it can be.
In this first video, we're going to cover probably the most important issue, and usually
the biggest vulnerability: passwords.
And as we'll see, the security of your passwords on your banking and e-commerce sites, as well
as anywhere else on the web where you log in, is dependent on two things: how good you
are at selecting a strong password, and how good a job the web server does at securing
it.
First, let's take a look at passwords that are not stored securely.
One of the biggest examples has to be the password fiasco on Adobe's website in October
of 2013.
As we look at what Adobe did wrong, we'll also see what users did wrong in selecting
a password.
Hackers managed to get into Adobe's website and steal their user database, where some
38 million users had their information exposed.
This included the encrypted passwords, but the encryption was done improperly.
Adobe used a block cipher to encrypt the passwords, and if you remember from Part I a block cipher
has a problem if you don't use an initialization vector to start a block chain.
Remember this picture of Tux and how information was leaked out?
The exact same thing happened here.
Here's a dump of a few of the records stolen via the hack.
Left to right, separated by dash-pipe-dash delimiters are, the user ID number, the username
(which most didn't have because the emails were used to log in), the email address (which
has been excised from this example), the encrypted password, and the password hint.
The password hint was in plain text, not encrypted, so it served as a basis for deciphering passwords.
The encrypted password was a block cipher which worked in 8-byte chunks.
Here's what it looks like, formatted a bit better.
The encrypted password has been converted to hexadecimal and displayed in 8-byte chunks
to show what's going on.
The top three, as the password hints show, is simply "123456," which, as a Mel Brooks
movie once observed, was the kind of thing an idiot would have on his luggage.
Here's the point: EVERY password that was "123456" got encrypted the exact same way.
Remember that if you use the same key on the same data without introducing any entropy,
you'll get the same encrypted result.
So thanks to these hints, we now know EVERYONE who used the password "123456."
Another commonly used password is "password."
You can see here that, again thanks to people being too free and open with their hints (my
favorite is, "rhymes with assword"), we now know how the word "password" gets encrypted
and can now tell ANY user that has used the password of "password."
Notice that "password" is 8 characters, but there's a second block.
The reason why is that, when you put a password--or anything else--into a database, there's an
extra byte at the end that's an end-of-field marker.
That second block doesn't have any password data, it's just the EOF.
So now we have information on how long other passwords are: if there's only one block,
then the password is less than 8 characters.
If it's exactly 8, the second block will be encrypted this way.
If it's more than 8, it'll have a different second block.
Remember that we do NOT want to give hackers ANY clue as to how long the password is.
But it does.
In this next group of passwords, although the first block is different, the second block
we can spot as the encrypted EOF.
So we know this password is precisely 8 characters.
And, in fact, the hints let us know that this password is simply "12345678."
So really, the password is broken down into groups of 8 encrypted characters.
This gives the hacker a BIG advantage: if he wanted to brute-force a password, he would
only have to do 8 characters at a time; once he got the first 8 characters, he could put
those aside and JUST work on the next 8.
This is REALLY bad.
You want password cracking to be an all-or-nothing prospect: you either get the entire password,
or nothing at all.
Moreover, since all these passwords were encrypted the same way, if you used one of these popular--and
insecure--passwords, even if you were sufficiently cryptic with your password hint you were vulnerable
if someone else used a giveaway hint, because your password was encrypted the same way.
Needless to say, this is NOT the way to secure passwords.
We've already seen how to do it in Part I: hash the password, don't encrypt it.
With a good hashing algorithm, there will be no clues given to the hacker as to how
long the password is.
But you'll STILL have this problem of people using the same password; remember that the
whole idea is that, since there's no decrypting a hash, the same password must result in the
same hash.
So if you use a password that rhymes with "assword," and so do a lot of other people,
and they give that away in the hints, they'll know that's YOUR password, too.
The way to get around this is to use a "salt."
This is simply a random number associated with each user account which gets appended
to the password.
So even if two people use the same password, they'll result in different hashes.
When the password is checked, the password the user types gets the same salt appended
to it, and the hashes of the SALTED passwords are compared.
Another way to secure their users' passwords would be to use "shadow passwords."
The idea is that there are a lot of processes that need various pieces of user data, like
their email address, but only one--the login process--that needs the passwords.
So what you do is make a separate table for the users' passwords, and ONLY the login process
has access to that.
So in that case, simply stealing the table of user data would NOT give them ANY way of
cracking the passwords; they'd have to get the shadow file as well, which can be kept
much more secure.
So far, we've covered how passwords should and should not be stored.
They should be hashed, not encrypted, they should be salted with a random number or sequence
of characters, and whenever possible, the passwords should be kept in a separate table
secured from everything except the processes that absolutely need it.
In the next video, Alice has created a password on Bob's server.
Bob has done everything right in storing the password as a salted hash, but nonetheless,
Eve has managed to get ahold of the hash of Alice's password.
So how does Eve use that to get Alice's password?
Stay tuned and find out.
And in the video after that, we'll look in more detail at how passwords should be stored
on servers and some of the stupid things they do which can compromise your password no matter
how good it is.