chris@GYRE.UMD.EDU (Chris Torek) (11/08/88)
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. (The phrase comes about from the fact that /etc/passwd is---or has, depending on your point of view---a `shadow' thrown by another file.) Chris
rick@SEISMO.CSS.GOV (Rick Adams) (11/09/88)
A better implementation of shadow passwords is not to replace the encrypted password field with * or something obvious, but to replace it with the correct number of random characters. Let the wouldbe cracker TRY and decrypt something that isn't encrypted! --rick
larry@pdn.UUCP (Larry Swift) (11/09/88)
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. ^^^^^^^ Updates of what?? Passwords? You still haven't explained what use /etc/passwd is, especially if the passwords in it are unusable! (I'm not a Unix guru, but curious nevertheless.) Larry Swift UUCP: {peora,uunet}!pdn!larry Paradyne Corp., LF-207 Phone: (813) 530-8605 P. O. Box 2826 Largo, FL, 34649-9981 She's old and she's creaky, but she holds!
jim@cs.strath.ac.uk (Jim Reid) (11/10/88)
In article <8811080049.AA07509@gyre.umd.edu> chris@GYRE.UMD.EDU (Chris Torek) writes: >.... a description of a 'shadow' (i.e. a dummy) password file > >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 (`*'). A more sneaky approach would be to replace the password field with something that looked like an encrypted password although it didn't cipher into anything significant. If you did that, the bad guy would waste his/her time on the usual password file attacks without getting anywhere. Putting something unusable (like `*') as the encrypted password would just tell the bad guy not to bother with that approach. That may or may not be a good thing. Jim -- ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
bill@UHCCUX.UHCC.HAWAII.EDU (William J. King) (11/10/88)
No problem, Ultrix encripts the passwords nicely! .
roberto@cwi.nl (Rob ten Kroode) (11/11/88)
In article <4871@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes: #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: [definition of shadow password files deleted] #You still haven't explained what use /etc/passwd is, especially if the #passwords in it are unusable! There is enough other information (besides the encrypted password) that is used by various programs. We *do* want to be able to get that information. Rob. -- | The two rules of Rob: Rob ten Kroode (roberto@cwi.nl) | rule #1 : I am _always_ right. | rule #2 : If I am not right, apply rule #1. "I'm your icecream man; stop me when I'm passin' by..." Van Halen
henry@utzoo.uucp (Henry Spencer) (11/12/88)
In article <4871@pdn.UUCP> larry@pdn.UUCP (0000-Larry Swift) writes: >You still haven't explained what use /etc/passwd is, especially if the >passwords in it are unusable! The slightly-misleadingly-named /etc/passwd file also contains the mapping between login name and internal user number, some information about the group(s) the user belongs to, the name of his home directory, the name of his command interpreter, etc. It's the central "user database" for the system. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
wisner@killer.Dallas.TX.US (Bill Wisner) (11/14/88)
The latest releases of System V (from AT&T R&D) have a shadow password file called /etc/private. The time at which a user's password was last changed is stored in private so password changing can be disallowed unless a certain time has passed. It also allows mandatory changing after a certain interval; but then, what doesn't? private can also contain a "dead login date" after which an account will be unusable.
ccs@mtune.ATT.COM (Chuck Schwing) (11/18/88)
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
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/23/88)
? From: rick@seismo.css.gov (Rick Adams) ? A better implementation of shadow passwords is not to replace ? the encrypted password field with * or something obvious, but to ? replace it with the correct number of random characters. Let the ? wouldbe cracker TRY and decrypt something that isn't encrypted! ? --rick My point exactly, except that DES is dense, that is, given all possible 64 bit codes input codes, all possible 64 bit codes will be generated. Upon reflection, this is obvious; were it not so, the algorithm would be unreversible (impossible to decrypt). BTW, there are four keys which which when applied twice reproduce the plaintext. That is, des_encrypt(des_encrypt(plaintext)) = plaintext. Two of them are all zeros and all ones. I don't know what the other two are. Of course, even with successful cracking in the above case, they wouldn't match the data in the shadow file. (Root Boy) Jim Cottrell (301) 975-5688 <rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa> Crackers and Worms -- Breakfast of Champions!