What should the password/security/userinfo/login system include?

[Larry Wall]

In article <1989Dec16.054850.5881 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
: In article <6602 at jpl-devvax.JPL.NASA.GOV> lwall at jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
: 
: >We disallow both of these.  The new password must be sufficiently different
: >from the old one.  You can't EVER reuse a password on our system, period.
: 
: Does this mean that you keep a file containing the old passwords around
: (like everyone has been saying is a security risk)?

Only old encrypted passwords.  And when was everyone saying anything about
old passwords?  I recall some discussion of logging failed attempts on
current passwords...

: >Password aging definitely improves security here.  I don't like it any
: >more than the users do, since I have to change their forgotten passwords
: >more often than they forget them (me being one and them being many).
: >But passwords do have a habit of leaking out from non-conscientious
: >users occasionally, so we have to punish the innocent with the guilty
: >in order to get the level of security we require.
: 
: I'm sure your requirements are a bit different than most systems, but
: has this really been demonstrated to be true?  Won't users be more
: likely to keep written copies of their password if they are required
: to change often?

It doesn't seem to happen much here.  Partly because we let people come
up with their own system of generating good passwords.  People naturally
prefer to come up with passwords they can remember.  At least on our
project, people wander from terminal to terminal, so they'd have to have
it in their wallet, or some such.  Dragging out your wallet every time
you want to log in is not *that* much fun.

And you may be right that our requirements are different than most systems--
we're currently much more worried about someone hacking their way in from
the outside, and such people probably wouldn't have physical access to a
written-down password anyway.  If someone within the project discovered
someone else's password, it wouldn't be a big deal, since most files
are shared within the project anyway.

: >You get a whole week's warning by mail here so you aren't suddenly forced
: >to think up a new password at an importune moment.
: 
: That would help, but only if you work on that system consistantly.  What
: if you need to connect to 5 or 6 different machines a few times a month?

Generally, there's someplace that you receive e-mail regularly, and you
can just forward you messages there.

: What if you want to make a machine connect and retreive something for
: you via an automatic login script?  I take it that you don't have any
: uucp logins on these machines... 

If I did, do you think I'd tell you?  :-)

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.

: >We have no extra stuff in our password file for aging.  The age in weeks,
: >modulo 64, is encoded into one of the salt characters (perturbed by the
: >first two characters of the login name so that salts are still randomly
: >distributed; also, the other salt character is still totally random.)
: 
: So you don't see any need to make the encrypted password unreadable?

There's some small value in that, but it's certainly not on the top of the
priority list, for us anyway.  There's nothing in our scheme that would
prevent the use of a shadow password file.

We're very serious about security here.  If someone's account is broken
into because of a lousy password, he can be fired.  If a machine is
broken into because of negligence on the part of the SA, he can be fired.
Gulp.

So we do a lot of stuff, security-wise, that I'm not even going to tell
you about.  If you bust security here, you can be sure I'm gonna try my
best to make sure it's not MY hide that gets nailed to the outhouse.

Larry Wall
lwall at jpl-devvax.jpl.nasa.gov