[Evans] The last thing we'll do this unit is look at an application
that combines many of the things we've seen so far.
Our goal is to figure out how to use passwords to do authentication.
We're going to assume that we have some file or database to keep track of users.
And for each user we want to keep track of something
that will allow us to authenticate that user.
In UNIX, this file is stored in /etc/passwd.
So our goal is that even if some malicious insider
or someone who can compromise our system can get access to the database
or the password file, they won't be able to impersonate users.
They won't be able to log in by just being able to read this file.
If they can modify this file, that's another story.
But let's assume that they can't modify it, they can just read it.
This is not a completely unrealistic model.
This is actually the model that motivated the design of the UNIX password system.
There are lots of people that need to read this password file
but only very privileged applications that need to write to it.
So the really bad idea number 1 is to just keep the passwords in clear text.
There actually are web applications that do that.
Any web application that actually does that is doing some things very, very wrong.
First of all, it's wrong to send a password in email,
especially one that was created by a user,
but it also means that they're actually storing your password
in a way that they can recover it.
And that probably means that anyone else who has access to their database
can also recover it. So we want to do something better.
We want to provide this property that even if someone can get access to the database
and read all the user and password information,
they can't break into your account.
So that was really bad idea number 0: keeping the passwords in clear text.
Now we're going to move on to really bad idea number 1,
which sounds a little bit more plausible but is not a good way to store passwords.
So here is the plan.
The server operator will generate some key.
Let's assume the server can generate a good random key.
And for each password we're going to store the encrypted value of that password,
encrypting using the key using CFB mode.
That's cipher feedback mode with message block size 8,
so that will allow us to use this for any size string.
8 is the number of bits per character.
That could be 7 or 8 depending on how we encode the characters.
The question is, why is this a really bad idea?
Here are all the possible choices.
Select all the ones that apply.
That it reveals the length of the password;
that the encrypted text reveals when 2 users have the same password;
that it requires use of E, an encryption function, which is slower than using a hash function;
that if the key is compromised, that reveals all of the passwords.
