Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!pacbell!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: What should the password/security/userinfo/login system include?
Message-ID: <1989Dec12.061055.2225@chinet.chi.il.us>
Date: 12 Dec 89 06:10:55 GMT
References: <4180@sbcs.sunysb.edu> <1989Dec7.172233.10130@chinet.chi.il.us> <1236@ispi.UUCP> <4217@sbcs.sunysb.edu>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Distribution: usa
Organization: Chinet - Chicago Public Access UNIX
Lines: 45

In article <4217@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:

>> >I want logging of *all* keystrokes during a failing attempt at logging
>> >in (more to allow me to help with the problem, but it would also
>> >help detect intruders).

>My login program does this; it even records the times between keystrokes.
>It runs in raw mode at the moment, though I'm considering switching back
>to cbreak. (Why does this imply that login and getty/telnetd need to be
>combined?)

Because I only want the failing logins logged. Getty accepts the
first line of input and has no way of knowing if the login will
succeed.  Since I want to be able to see the raw characters, the
(possibly editted) line handed to login isn't good enough.
Besides, I'd like to see a speedup in the login process.

>> This is not a good idea.  If someone unauthorized sees this log file
>> they would have a fairly good idea of some of the passwords on the
>> system.

>All password characters (except backspace and newline) are replaced by x.
>The information loss does not outweigh the security gain.

This is the most reasonable suggestion so far, but when a login fails
it is pretty difficult to tell which piece you are not interpreting
correctly.  If you pick up a couple of CR's from modem noise you could
still manage to get both the login and password in the visible part.
I'd be perfectly happy to encrypt the whole thing.  Can someone suggest
a way to handle the encryption key other than the obvious method of
compiling it into the program?

Now to put the problem in perspective, the machine where I would most
like to see this sort of logging runs a subscription information
database.  There are >1K users in the passwd file, most of whom don't
know anything about computers and aren't interested in learning - they
just want their automated communication program script to login and
grab a set of files for them.  Almost no one on the machine gets a
real shell - just a program that prompts for requests, logs them and
hands them out.  The sensible thing might be to make this program
also perform the getty/login functions on the dial-up lines but it
seems somehow against the unix "philosophy".

Les Mikesell
  les@chinet.chi.il.us