Article View: sci.crypt
Article #4083Re: Unix Password Hacker
From: Jonathan I. Kamens
Date: Sun, 28 Feb 1988 16:39
Date: Sun, 28 Feb 1988 16:39
77 lines
4924 bytes
4924 bytes
In article <1043@athos.rutgers.edu> webber@athos.rutgers.edu (Bob
Webber) writes:
>In article <3234@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan
>I. Kamens) writes:
>> [my initial, partially incorrect explanation of kerberos]
>Hmmm. Clearly this isn't the whole story. Sending the encrypted
>password down the pipe to be read and matched against an entry doesn't
>of itself add anything to security since anyone can duplicate a
>transmission of an encrypted password as easily as a raw password. In
>order to get security, besides encryption, you need some kind of
>handshaking protocol that allows the permission-granter to ascertain
>that the sender really knows the unencrypted password and is not just
>duplicating an intercepted encrypted transmission. Note that if you
>can monitor a users encrypted traffic, given the stereotyped nature of
>computer traffic, many attacks are possible.
You are totally correct, and my first explanation of kerberos' initial
authentication was incorrect.
Allow me to quote without permission from "Kerberos: An Authentication
Service for Open Network Systems," a paper by Jennifer G. Steiner,
Clifford Neuman and Jeffrey I. Schiller which was presented at the
1988 Usenix Conference held recently in Dallas, Texas. They say it
much better than I could.
Getting the Initial Ticket
When the user walks up to a workstation, only one piece of
information can prove her/his identity: the user's password. The
initial exchange with the authentication server is designed to
minimize the chance that the password will be compromised, while
at the same time not allowing a user to properly authenticate
her/himself without knowledge of that password. The process of
logging in appears to the user to be the same as logging in to a
timesharing system. Behind the scenes, though, it is quite
different.
The user is prompted for her/his username. Once it has been
entered, a request is sent to the authentication server
containing the user's name and the name of a special service
known as the ticket-granting service.
The authentication server checks that it knows about the
client. If so, it generates a random session key which will
later be used between the client and the ticket-granting server.
It then creates a ticket for the ticket-granting server which
contains the client's name, the name of the ticket-granting
server, the current time, a lifetime for the ticket, the client's
IP address, and the random session key just created. This is all
encrypted in a key known only to the ticket-granting server and
the authentication server.
The authentication server then sends the ticket, along with a
copy of the random session key and some additional information,
back to the client. This response is encrypted in the client's
private key, known only to kerberos and the client, which is
derived from the user's password.
Once the response has been received by the client, the user is
asked for her/his password. The password is converted to a DES
key and used to decrypt the response from the authentication
server. The ticket and the session key, along with some of the
other information, are stored for future use, and the user's
password and DES key are erased from memory.
Once the exchange has been completed, the workstation possesses
information that it can use to prove the identity of its user for
the lifetime of the ticket-granting ticket. As long as the
software on the workstation had not been previously tampered
with, no information exists that will allow someone else to
impersonate the user beyond the life of the ticket.
I hope this clarifies things. It is a little bit confusing, I admit.
My error was in stating that the user's password travels over the
network in DES-encrypted form. In fact, the password never travels
over the net in any form at all.
-=> Jonathan I. Kamens | "There is no expedient to which man will not go
MIT '91 | to avoid the real labor of thought."
jik@ATHENA.MIT.EDU | -- Thomas Alva Edison
Technical Details
Message-ID:
<3319@bloom-beacon.MIT.EDU>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!bloom-beacon!athena.mit.edu!jikReferences:
<731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <3234@bloom-beacon.MIT.EDU> <1043@athos.rutgers.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: sci.crypt Subject: Re: Unix Password Hacker Message-ID: <3319@bloom-beacon.MIT.EDU> Date: 28 Feb 88 16:39:44 GMT References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <3234@bloom-beacon.MIT.EDU> <1043@athos.rutgers.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Distribution: na Organization: Massachusetts Institute of Technology Lines: 77