Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!bionet!agate!shelby!PIT-MANAGER.MIT.EDU!jik From: jik@PIT-MANAGER.MIT.EDU ("Jonathan I. Kamens") Newsgroups: comp.protocols.kerberos Subject: Why is initial user authentication done the way it is? Message-ID: <9006150549.AA24093@PIT-MANAGER.MIT.EDU> Date: 15 Jun 90 05:49:54 GMT References: <9006150126.AA22710@E40-008-10.MIT.EDU> Sender: daemon@shelby.Stanford.EDU Organization: The Internet Lines: 140 Date: Thu, 14 Jun 90 21:26:25 -0400 From: Bill Sommerfeld 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