[998] in Kerberos
Re: Why is initial user authentication done the way it is?
daemon@ATHENA.MIT.EDU (Joe Pato)
Thu Jun 14 17:44:11 1990
From: pato@apollo.com (Joe Pato)
Date: Thu, 14 Jun 90 16:05:18 EDT
To: jik@pit-manager.MIT.EDU ("Jonathan I. Kamens")
Cc: mdl@B.GP.CS.CMU.EDU, kerberos@ATHENA.MIT.EDU
In-Reply-To: jik@pit-manager.MIT.EDU ("Jonathan I. Kamens"), thu, 14 jun 90 14:36:22
From: Mark Lillibridge <mdl@B.GP.CS.CMU.EDU>
Date: Thu, 14 Jun 90 11:06:42 EDT
The short answer: Because this scenario is also vulnerable to a
dictionary attack. Suppose I wanted to break your password under the
new scheme. I just wait until you log in, recording your data request
in part 1. I now pretend to be Kerberos, and try and decrypt your
initial request with each possible key until I succeed. Once I have a
key that successfully decodes your request, I have found your key.
From: jik@pit-manager.MIT.EDU ("Jonathan I. Kamens")
This assumes that you have the ability to monitor transactions going
over the network. The way things stands now, you do not need to be
able to do this in order to get an encrypted packet to hack on,
whereas in the proposed system I described, you do; therefore, my
system provides at least some level of increased security.
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.
-- Joe Pato
Cooperative Object Computing Operation
Hewlett-Packard Company
pato@apollo.hp.com
-------
