V1.81 (Shadow passwords)
Keith Bostic
bostic at OKEEFFE.BERKELEY.EDU
Wed May 10 05:15:04 AEST 1989
Subject: Shadow passwords
Index: lib 4.3BSD-tahoe
Description:
A shadow password implementation is now available from
Berkeley, and will be a standard part of the next 4BSD
distribution. The following describes the package in more
detail. To get copies of the package, send electronic mail
to ucb-fixes-request at ucbvax.berkeley.edu, or call the BSD
distribution office at 415-642-7780.
In the current BSD system, there are three password
files: /etc/passwd, /etc/passwd.pag, and /etc/passwd.dir.
The first is the password file as described in passwd(5);
the others are files containing an ndbm(3) style hashed
database version of /etc/passwd.
In the new system, there are four password files:
/etc/passwd, /etc/master.passwd, /etc/passwd.pag, and
/etc/passwd.dir. The first is exactly as it has always been
with the exception that the encrypted password field has
been replaced with a single asterisk. The next three files
have much the same relationship as the original model;
master.passwd is the new password file, and passwd.pag and
passwd.dir comprise the ndbm version. The one difference
between the contents of master.passwd and the contents of
its ndbm files is that only master.passwd has the encrypted
form of the password. The ndbm files have, instead, its
offset in master.passwd. Note, the file /etc/passwd is no
longer used for anything, it is simply left in place for
backward compatibility with shell scripts.
The model we are using assumes that standard, non-
privileged programs do not need to look at the encrypted
form of the password. Therefore, we have altered the
getpwent(3) routines to read the standard data from the ndbm
files, and only attempt to read and return the encrypted
password if the process is running as super-user. Obvi-
ously, master.passwd is read/writable only by the super-user
and and the ndbm files are readable by anyone and writable
only by the super-user.
We also added three new fields to the password file; a
``change'' field, for password aging, an ``expire'' field,
for account expiration, and a ``class'' field for everything
else. The first two are implemented in login(1), and are,
respectively, the date by which the password must be
changed, and the date when the account expires. The third
will be part of the next 4BSD release, but is currently
unimplemented. It will be a ``pointer'' to a termcap style
database that may be used to store site-dependent informa-
tion about a user, from when the user may be allowed to log
into the system, to how often the user is required to change
their password.
The include file, pwd.h, has changed in fairly major
ways. We've deleted the two unused fields, ``pw_quota'',
and ``pw_comment'', and replaced them with ``pw_change'' and
``pw_class'', respectively. The other new field,
``pw_expire'', has been added at the end of the structure.
The only known problem with the current implementation
of password aging is that there is no ``reset'' -- when the
user changes his or her password it essentially shuts off
password aging for that user. To reenable aging, an
administrator will have to use vipw(8) or chpass(1) to pro-
vide a new password timeout. We expect to remedy this with
the new ``class'' database, where one of the provided fields
will be a value specifying how often the password needs to
be updated. Once this is in place, passwd(1) will simply
reset the password timeout value each time the user changes
their password.
Two programs have been deleted by this package, chfn(1)
and chsh(1). They are replaced by the much more comprehen-
sive program chpass(1). The other programs affected by this
package behave much like they have always behaved.
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list