[1007] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Fri Jun 15 02:43:43 1990
Date: Fri, 15 Jun 90 01:49:54 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: wesommer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Thu, 14 Jun 90 21:26:25 -0400 <9006150126.AA22710@E40-008-10.MIT.EDU>
Date: Thu, 14 Jun 90 21:26:25 -0400
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Sure there is. All I have to do is get a valid TGT, and then ask the
KDC for a ticket to jik@ATHENA.MIT.EDU. The response will include a
"ticket to jik", which will contain my name (and other things)
encrypted in your key. I can then bang on the ticket all I want in
the privacy of my own CPU.
Remember that in Kerberos there is no difference between users and
servers.
Indeed. Cliff Neuman and Tim Shepard have both managed to make this
clear to me (I had been overlooking it) in private E-mail, and I have
explained it to the people who originally raised this point to me.
After spending about as much time explaining it to them as Cliff and
Tim had to spend explaining it to me before I realized the problem
:-), their response was, "Oh, you're right." They couldn't come up
with any solution to this problem, and neither can I, at this point.
Several people have challenged my claim that it's easier to break
into a Kerberos-authenticated machine than it is to break into a
machine using standard Unix security, both here and in private E-mail.
I still claim that this is the case, and I will respond here to the
various points that people have made.
First of all, let me reiterate why I still think this is a problem.
In the description below, "Unix" is short for the tradiitional Unix
authentication system:
1. Under Unix, you have to have an account on a properly configured
machine in order to get a hole of the passwd file. Under Kerberos,
anyone on the Internet can request an encrypted sample of anyone to
bang on it.
2. Under Unix, every possible password must be encrypted using every
possible seed in order to match against strings in the passwd file.
Under Kerberos, this isn't necessary -- just run string_to_key over
all of your possible passwords and they can immediately be used for
decryption attempts.
3. The crypt() function under Unix is meant to be slow. Kerberos'
decryption of the tgt is faster, significantly. Furthermore, it's
straight DES, so anyone who is serious about cracking passwords can
use all of the available DES hardware to do his cracking.
In summary, it's easier to get a hold of encrypted Kerberos data to
play with than it is to get a hold of /etc/passwd data, and playing
with it is faster.
Now, to answer the various questions people have asked. Cliff
Neuman says:
Although I havn't contested that claim, I am not quite sure that I
understand it. I believe that with confounders at the start of
all ciphertext (as will be the case in V5), a pre-computed
dictionary attack is ruled out, and the difficulty of a brute
force attack on verifiable plaintext is of the same order of
difficulty (constant factor) as a brute force attack on a Unix
password.
The confounder does make it impossible to encrypt lots of copies of
the tgt that you think you'll get, and then compare it to the tgt you
actually get. However, the counfounder does not (as I understand it;
please correct me if I'm wrong) change the fact that passwords need
only be run through string_to_key (i.e. you don't have to change the
encryption of the password based on the confounder), and that DES is,
or can be made, much faster than crypt().
One of the main objections to traditional Unix security is that when
it was designed, machines were slow enough that the crypt() function
provided somewhat adequate protection, while nowadays things are so
much faster that it is possible to employ a brute-force attack on
Unix. It is my claim that it is *even easier* to employ a brute-force
attack against Kerberos.
Jerry Saltzer says:
1. Dictionary attacks originated when people discovered that they
could ftp or otherwise steal a copy of /etc/passwd and get a whole
bunch of user names and encrypted passwords to work on; they pay
off because out of several hundred or thousand candidates a few
will probably yield. With Kerberos you have to know the name of
the user you want to attack. A random hacker in California may be
able to attack jik, because he saw your id on a usenet bulletin
board, but he can't tackle all 10000 Athena user id's looking for
a few that yield to the dictionary. So the available attack is a
different one from the one the hackers use, and in some ways less
useful.
My response is two-fold. First of all, it is my opinion that it is
unreasonable to base the security of a system on whether or not it is
easy to get usernames for that system. What happens when your school
publishes a student directory with usernames in it? What happens when
the directory gets put on line (For an example of this, try typing
"finger John@athena.mit.edu" or "finger Wu@mit.edu".)? Second, a
recent examination of the passwords in Athena's Kerberos database
revealed that over 30% of the passwords were guessable. This included
all machine service keys, which means that an even higher percentage
of actual user passwords were guessable. This means that if I can get
ten Athena usernames (through the mechanisms I described above or
perhaps just by guessing common usernames based on the way Athena
usernames are formed by default and on other methods), I will on
average be able to break three of those usernames easily. What all
this means is that whether or not I can read the whole passwd file is
irrelevant -- I remind you that there are lots of ways to get
usernames, and besides that, Kerberos *tells* you when you ask for a
username that isn't valid.
Jerry continues:
BSD-supplied security system has holes you can drive a Mack truck
through (passwords on the net in the clear, .rhosts files in
private directories, wide-open NFS, etc.). Kerberos cleans all
that up and provides a huge improvement in system security in a
dozen areas; it provides essentially no improvement in some other
areas. And here are people (not you, but some of the others
responding to this discussion) claiming that Kerberos might as
well be trashed because it is no better than the original UNIX
security! Somehow we need to get some perspective back into the
picture.
Then, in another message to me, he says:
In my previous message, I guess I let you off the hook too easily.
You are a little over the edge with that comment! I assume you
mean only that dictionary attacks can go faster?
Yes, Jerry, I'm talking only about dictionary attacks here, and I do
believe that they can go significantly faster and are more vulnerable
than are dictionary attacks under Unix. And yes, I agree with you
that Kerberos has claned up the garbage in BSD protections and
provided huge improvements in many areas; I just think that this
particular area is much too vulnerable.
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
