Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!aurora!eos!ames!hao!boulder!sunybcs!rutgers!aramis.rutgers.edu!athos.rutgers.edu!webber
From: webber@athos.rutgers.edu (Bob Webber)
Newsgroups: sci.crypt
Subject: Re: Unix Password Hacker
Message-ID: <1043@athos.rutgers.edu>
Date: 28 Feb 88 07:59:04 GMT
References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <3234@bloom-beacon.MIT.EDU>
Distribution: na
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 24

In article <3234@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes:
> ...  However, we are at a large advantage in the area of
> /etc/passwd hacking, because usernames and passwords DO NOT APPEAR
> anywhere at all that is user-accessible, and they are never sent over
> the network in plaintext as is done when telnet'ing or rlogin'ing.
> Instead, when a user types in his password it is encrypted and sent to
> the kerberos-server, which compares it with its (crypted) password
> entry for the user.  If they match, the user passes, and if not, he
> hasd to login again.

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.

Does kerberos really address such issues?

------ BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)