[1000] in Kerberos
Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Thu Jun 14 20:25:14 1990
Date: Thu, 14 Jun 90 19:37:48 -0400
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: pato@apollo.com
Cc: (), mdl@B.GP.CS.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: Joe Pato's message of Thu, 14 Jun 90 16:05:18 EDT <9006142003.AA02833@xuucp.ch.apollo.com>
From: pato@apollo.com (Joe Pato)
Date: Thu, 14 Jun 90 16:05:18 EDT
There is no substitute for well selected passwords. Even if the TGT
acquisition protocol were made more "secure" by forcing the initiator to
transmit an encrypted request there are still simple dictionary attacks. If
you want to attack another principal's passwords simply request a ticket for
that principal. The ticket you receive from the KDC includes verifiable
plaintext that is encrypted in the target principal's key.
First of all, see the message I just sent in response to Cliff for
my response to the "There is no substitute ofr well selected
passwsords" argument. I won't bother to repeat it here.
Second, you appear to be misunderstanding what I am proposing. If
the user has to send the server a pre-authenticated (e.g. encrypted in
the user's key) piece of data before the server will send back a tgt,
then there is no way to get an encrypted ticket to bang on without
first proving to the server that you are who you claim to be.
Brute force becomes unuseable in this context because a brute force
attempt to convince the server that you are the right person would
require you to send thousands (if not tens, or hundreds, or thousands
of thousands) of pre-authenticated requests to the server, and such
repeated failing requests would show up in the logs.
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710
