Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!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: <1989Dec20.192757.19899@chinet.chi.il.us>
Date: 20 Dec 89 19:27:57 GMT
References: <4180@sbcs.sunysb.edu> <1989Dec7.172233.10130@chinet.chi.il.us> <7284@ficc.uu.net> <1989Dec16.054850.5881@chinet.chi.il.us> <6629@jpl-devvax.JPL.NASA.GOV>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Distribution: usa
Organization: Chinet - Chicago Public Access UNIX
Lines: 33

In article <6629@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:

>The straight answer is that we don't have to age every account.  And we
>don't run much uucp.  And automatic retrieval with rcp is unrestricted within
>the project.  (We expire external hostnames in .rhosts files regularly.)
>We don't WANT people writing automatic retrieval scripts from outside.
>That, in my mind, is a very good argument *for* expiring passwords.

But, the whole purpose of the machine in question (i.e. the original
topic of logging bad logins), is to collect and store data to be
retreived on demand.  A typical session is about 2 minutes of on-line
time, and most of the data is updated at least daily, some every 10
minutes (it's an agricultural-related database with commodity futures
and options listings, market reports from the USDA wire service, advice
from various sources, etc.).  Thus, even if someone breaks in, they
have to keep doing it to keep getting current information.  We expect
people to use automated scripts to log in since it would be pretty boring
to do it yourself several times a day.  We also broadcast this stuff over
a couple of satellite links - if someone wants to steal it they would
probably try to get it that way instead.  Still, we have contractual
requirements with the information providers to limit access (getting
serious now that we are going to offer live tick-by-tick stuff from
the commodity exchanges) and I don't want to do anything foolish. 
However, I do have to deal with the problem of users being unable to
log in, and a log of the failed attempts would be most helpful.
Users don't get a real shell on this machine - just something that
asks for requests and doles them out.  Based on some magic stuff in
the comment field in the password file (most don't get a HOME directory)
they may be able to access mail and a few other things, but they
can't go wandering around reading files at random.

Les Mikesell
  les@chinet.chi.il.us