Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!bellcore!faline!sword!arrow!yba
From: yba@arrow.bellcore.com (Mark Levine)
Newsgroups: news.sysadmin
Subject: Password support
Message-ID: <931@sword.bellcore.com>
Date: 11 Nov 88 16:56:52 GMT
References: <22401@cornell.UUCP> <4627@rayssd.ray.com>
Sender: news@sword.bellcore.com
Reply-To: yba@sabre.bellcore.com
Organization: Bellcore, Red Bank, NJ
Lines: 59

In article <4627@rayssd.ray.com> gmp@rayssd.RAY.COM (Gregory M. Paris) writes:
>Encouraging the use of more password selection methods is what is really
>desired.

Not only must you choose something you can remember, but it must be something
relatively secure against guessing, and it must be changed regularly to prevent
the "kid with a pc" from doing exhaustive generate and match runs against it.

I was given some software by another group here to help tighten password
administration, and even if it becomes known, the generator a cracker will
build is still acceptable.  The scheme is also easier on the administrator
if somewhat bothersome for the user:

	- modify /bin/passwd (on your central server if you distribute the
	  passwd file) to require that all passwords are at least 7 characters
	  in length, have at least one upper-case and one lower-case letter,
	  and one non-alphabetic character.  This immediately removes short
	  passwords, dictionary entries and passwords which match the user
	  name (in _most_ cases!).  The patches are straightforward, but I
	  don't have the author's leave to post them (yet, and since the author
	  has not, I question whether I will obtain same).

Then comes the problem of getting people to use it.  If you distribute the
password file, then all slave machines get a dummy program that tells the
user to log in to the central password machine and change passwords, which
becomes the shell in /etc/passwd.  On the master machine, this program is
the real one.  It is named as "needpass_sh" (or _csh or _ksh) on both types,
indicating what shell to restore after the password has been changed.

The program then requires the user to know:

	- the old password to log in

	- some piece of other data (or even a pass-algorithm) to convince
	  the program this is indeed who we think (perhaps a file of less than
	  public data to match against: SS#, boss, first day on job)


and runs the new passwd program for the user, logs the entry, and uses
chsh to restore the old shell (then the file is propagated in the distributed
scheme).  We have a database in the company that helped with selecting the
"other data" and that I don't want to describe in detail.

Having something like this allows you to get people to change their passwords
on a regular basis, because you can just edit all shell entries in /etc/passwd
to the needpass_* name whenever the "age" acceptable to you arrives.  Should
be about every 90 days with a password so constructed (but I don't keep up with
theory, so let me know of this is optimistic!).

When it was explained to local users that crackers had been working on old
copies of our /etc/passwd, they were both understanding and cooperative, even
though I screwed it up on the first run for 30 of them (remember to make sure
that /bin/chsh believes all your local shells are valid!).  This is also a
great way to find out who your ex-users and non-users are (after 30 days of
unchanged shell).  If you can exchange email and are interested in more detail,
please get in touch.

Eleazor bar Shimon, once and future Carolingian
yba@sabre.bellcore.com