Article View: sci.crypt
Article #4063Re: Unix Password Hacker
From: Jonathan I. Kamens
Date: Fri, 26 Feb 1988 07:57
Date: Fri, 26 Feb 1988 07:57
58 lines
3690 bytes
3690 bytes
In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes:
>
>But what purpose does this serve? The first time the owners of the accounts
>try to login and find they can't, they're going to make a phone call to the
>data processing people who will just assign a new password right there over
>the phone.
>
First, there is, of course, the previously mentioned hacks to the
filesystem, such as the .profile hack to get a user's new password.
This alone is enough to make the standard password assignment too
dangerous to use.
Second, the hacker could post to the Usenet under the stolen
account, or send harrassing e-mail to other users on the system, etc.,
etc.
Third, the hacker could do hacking-type things on the stolen account
that he would never dare do on his own account, for fear of them
showing up on the system log. For example, taking up massive amounts
of CPU time hacking passwords that AREN'T "nopassword."
Consider the following situation, though, which is what things are
like here at Project Athena at MIT: we use a workstation/server system
instead of a timesharing system. This means that each workstation is
a unix machine in its own right (They each have separate Internet
addresses, too.). Since any user can bring up a workstation in
single-user mode by hitting the halt button and bringing it back up,
the workstations are totally insecure; therefore, the root password is
publicly available as part of Project Athena policy. This does not
ruin network security, because everything outside of the workstation
itself is kerberos-authenticated. However, it is a simply matter for
an intelligent programmer (or even a not-so-intelligent one) to write
a program (a shell-script, even) which pretends that it's a login
window until a user types in his name and password, then mails the
password to the hacker, then kills the hacker's shell automatically.
Since workstations fail on login quite a bit when the network is
operating slowly, the user would simply assume that login failed and
login again, but by that point it is too late.
So, we've given up a small amount of security by going to
workstations. 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.
Personally, I think our way is safer. Unfortunately, most colleges
can't afford 650 VAXstations and IBM PC/RT's to use for workstations.
Of course, neither can MIT.... we got them on a grant. :-)
-=> 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:
<3234@bloom-beacon.MIT.EDU>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!bloom-beacon!athena.mit.edu!jikReferences:
<731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <739@ddsw1.UUCP> <1118@uop.edu> <2584@crash.cts.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: sci.crypt Subject: Re: Unix Password Hacker Message-ID: <3234@bloom-beacon.MIT.EDU> Date: 26 Feb 88 07:57:42 GMT References: <731@ddsw1.UUCP> <657@morningdew.BBN.COM> <1368@homxc.UUCP> <739@ddsw1.UUCP> <1118@uop.edu> <2584@crash.cts.com> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Distribution: na Organization: Massachusetts Institute of Technology Lines: 58