Path: utzoo!attcan!uunet!husc6!rutgers!att!mtune!ccs
From: ccs@mtune.ATT.COM (Chuck Schwing)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <7874@mtune.ATT.COM>
Date: 17 Nov 88 20:58:12 GMT
References: <8811080049.AA07509@gyre.umd.edu>
Reply-To: ccs@mtune.UUCP (Chuck Schwing)
Organization: AT&T ISL Middletown NJ USA
Lines: 34

In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes:
>It seems the phrase `shadow password file' is not well known, so here
>is a definition:
>
>It means the encrypted passwords themselves (and any other `sensitive'
>information) is not kept in /etc/passwd, which is readable by everyone,
>but rather in some other file that is not readable except by root
>(and/or by other privilege of your choice).  The typical implementation
>is to rename the real password file /etc/passwd as something else
>(e.g., /etc/pw.shadow), and replace /etc/passwd with a copy that has
>the password field replaced with something unusable (`*').  Programs
>that really need a user's password run privileged, and are changed to
>refer to the shadow file; others use the usual file, but have no access
>to the encrypted password.  Updates must happen to both files.


This is all true.  A good idea, however is to leave the passwd entry in the original
/etc/passwd either the original root password or leave the password field in the 
original nulled out.

This will allow root to get back in should the unthinkable happen:

Your /etc/shadow file gets blown away.

This little scheme will only work if you have source code for login and make it
look in either /etc/shadow or /etc/passwd when checking a user's password 
entry.
Obviuosly, I guess everybody doesn't have the source so this
tip is not of real general use, but for those who do have the
source code, this can save real headaches at some future date.


Take care,
Chuck Schwing		ccs@mtune.att.com