Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!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: <9006152012.AA25441@PIT-MANAGER.MIT.EDU>
Date: 15 Jun 90 20:12:10 GMT
References: <9006151300.AA24937@PIT-MANAGER.MIT.EDU>
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 30


  Perhaps I'm confused, but it seems to me that if crypt() is doing
25 encryptions, and Kerberos DES is doing 1, then crypt() is going to
be slower than Kerberos DES.

  Furthermore, if you have a database of passwords you want to try in
your attack, crypt() requires you to encrypt each of them 4096 times
(64 characters are legal in the seed, and there are two seed
characters), which means you've got 4096 times as many passwords to
store in your password database.

  Granted, Unix encryption does have the added problem that once you
*do* do all of those crypt()s, the database you have needs only be
compared to the passwords you're trying to crack using strcmp() (or
its equivalent), rather than having to do an encryption using them as
the key.  However, I'm not sure how relevant this is, since the type
of atack I'm going to do on a Kerberos tgt isn't really the same as
the type of attack I'm going to use on a Unix password.

  One final note -- one of the big mistakes made in the design of Unix
authentication is that it assumed that machines were slow enough that
brute-force attacks would not be feasible.  We all know that nowadays,
this is more and more no longer the case.  Therefore, do we want to
make the same assumption, and same mistake, in the design of the
Kerberos authentication scheme?

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710