Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!decwrl!ucbvax!
GYRE.UMD.EDU!chris
From: ch...@GYRE.UMD.EDU (Chris Torek)
Newsgroups: comp.protocols.tcp-ip
Subject: password aging (from worm discussion)
Message-ID: <8811070715.AA05179@gyre.umd.edu>
Date: 7 Nov 88 07:15:13 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35
Be *very* careful how you implement password aging. If it is done
improperly, it weakens security instead of strengthening it. For
instance, if the system demands that you replace your password once
every two weeks, and demands that you replace it immediately upon
logging in, users are likely to use `easy' passwords and/or write them
down, since they must remember them only for a short while and since
they have little time to think of a new one.
At any rate, we intend to implement shadow password files here (at U of
MD CSD) if Berkeley does not get to it first. The way the worm breaks
Unix passwords is by efficiently implementing the Unix `salted' DES
encryption (possibly the worm's author simply used Bob Baldwin's code),
and doing forward encryption on each of the passwords from its
dictionary lists for each account. If the encrypted passwords are not
readable except from privileged accounts, this method is not available;
the program must instead go through standard accessways such as the
`login' program, which were long ago instrumented to be able to log
apparent breakin attempts. (Of course, all of this assumes that one is
unable to exploit some existing bug that gives privileged access. It
also assumes that your Unix vendor has at least kept up with Berkeley's
security improvements since 4.2BSD.)
We already enforce `hard to guess' passwords---dictionary checking is
in 4.3BSD-tahoe, and we had been using similar checking earlier---and,
by some stroke of luck, we had modified the finger daemon, and had a
piggish sendmail: the worm gave it a mere 20 seconds to establish
connections, and we no doubt timed out. At any rate, the worm never
got established on any UMD CSD machine (though other departments were
affected); but the potential was there, and that is rather
frightening. The possibility of an efficient brute-force attack on
other user's accounts, given an unprivileged account (as the finger bug
did), is much more so. Shadow password files suddenly look quite
attractive. . . .
Chris
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!
ucbvax!GYRE.UMD.EDU!chris
From: ch...@GYRE.UMD.EDU (Chris Torek)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <8811080049.AA07509@gyre.umd.edu>
Date: 8 Nov 88 00:49:20 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 17
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
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!
bloom-beacon!bu-cs!purdue!decwrl!ucbvax!SEISMO.CSS.GOV!rick
From: r...@SEISMO.CSS.GOV (Rick Adams)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <8811081644.AA20572@beno.CSS.GOV>
Date: 8 Nov 88 16:44:49 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 6
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
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!
rutgers!ucsd!ucbvax!SUN.COM!gww
From: g...@SUN.COM (Gary Winiger)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: password aging (from worm discussion)
Message-ID: <8811100214.AA06002@marduk.Sun.COM>
Date: 10 Nov 88 02:14:10 GMT
References: <8811070715.AA05179@gyre.umd.edu>
Sender: use...@ucbvax.BERKELEY.EDU
Reply-To: g...@Sun.COM (Gary Winiger)
Organization: Sun Microsystems, Mountain View
Lines: 23
In article <8811070715.AA05...@gyre.umd.edu> ch...@GYRE.UMD.EDU (Chris Torek)
writes:
>
>At any rate, we intend to implement shadow password files here (at U of
>MD CSD) if Berkeley does not get to it first. The way the worm breaks
>Unix passwords is by efficiently implementing the Unix `salted' DES
>encryption (possibly the worm's author simply used Bob Baldwin's code),
>
>We already enforce `hard to guess' passwords---dictionary checking is
>in 4.3BSD-tahoe, and we had been using similar checking earlier---and,
Chris,
Some time in Jan, I posted a set of mods to 4.3 that I did while at
ELXSI (with their permission) to implement shadow password files, password
aging, and stronger password criteria. The were posted to alt.sources
with a note in comp.bugs.4bsd. I also sent a copy to Keith Bostic. You
may wish to look at that. If it doesn't meet you needs, it might serve
as a starting point and illustrate a possible approach. If you'd like to
get a copy, drop me a note and I'll return the shars by mail.
Gary..
g...@Sun.COM
P.S. I'll be traveling from 14 - 20 Nov. so replies won't happen until 21 Nov.
Path: utzoo!attcan!uunet!pdn!larry
From: la...@pdn.UUCP (Larry Swift)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <4871@pdn.UUCP>
Date: 9 Nov 88 13:26:23 GMT
References: <8811080049.AA07509@gyre.umd.edu>
Reply-To: la...@pdn.UUCP (0000-Larry Swift)
Organization: Paradyne Corporation, Largo, Florida
Lines: 26
In article <8811080049.AA07...@gyre.umd.edu> ch...@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!
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!
uwmcsd1!marque!uunet!mcvax!ukc!strath-cs!jim
From: j...@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <1260@stracs.cs.strath.ac.uk>
Date: 9 Nov 88 18:07:35 GMT
References: <8811080049.AA07509@gyre.umd.edu>
Reply-To: j...@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 23
In article <8811080049.AA07...@gyre.umd.edu> ch...@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...@ucl-cs.arpa, j...@cs.strath.ac.uk
UUCP: j...@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET: j...@uk.ac.strath.cs
"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: shadow passwords?
Message-ID: <1988Nov11.165853.19955@utzoo.uucp>
Organization: U of Toronto Zoology
References: <8811080049.AA07509@gyre.umd.edu> <4871@pdn.UUCP>
Date: Fri, 11 Nov 88 16:58:53 GMT
In article <4...@pdn.UUCP> la...@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 he...@zoo.toronto.edu
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!
bloom-beacon!apple!bionet!agate!ucbvax!killer.Dallas.TX.US!wisner
From: wis...@killer.Dallas.TX.US (Bill Wisner)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: shadow passwords?
Message-ID: <m0eITJL-00000JC@killer.Dallas.TX.US>
Date: 13 Nov 88 20:26:42 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 6
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.
Path: utzoo!attcan!uunet!convex!killer!osu-cis!tut.cis.ohio-state.edu!
ukma!nrl-cmf!ames!pasteur!ucbvax!pinocchio.UUCP!bzs
From: b...@pinocchio.UUCP (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: password aging (from worm discussion)
Message-ID: <8811171612.AA19137@pinocchio.UUCP>
Date: 17 Nov 88 16:12:43 GMT
References: <8811100214.AA06002@marduk.Sun.COM>
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33
Although I support the other proposals I will argue that shadow
password files are a bad idea (actually, I'm not too enamored with
password aging, others have argued against this questionable idea.)
It means that if, for any reason, you believe your password file has
been let out you will have to admit that your security is compromised
and, for starters, have everyone change their password (then spend
your time "improving" the file's security etc.) You better also
develop effective means of detecting whether anyone has read your
password file or printed it out and not disposed of it properly.
You're turning the file into pure gold.
I still am confident that with methods like password changing programs
which try to prod the user to choose a reasonable password AND
education of users (perhaps backed with some internal enforcement,
such as removing accounts that insist on trivial passwords, whatever
your organization needs) the current publicly readable file affords
MORE security than a shadow file.
I sincerely hope that the community consider this matter before it
becomes some sort of standard. I believe it compromises security by
creating more problems than it solves, complicates security
administration by requiring strict controls on who can access the file
and creates new security crises when the file is believed to have been
read by someone unauthorized.
I fear that everyone is currently running willy-nilly trying to find
*something* to do in response to this worm, let's not, in the heat of
the moment, commit to something that actually makes matters worse.
-Barry Shein, ||Encore||
Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!agate!ucbvax!
UC.MSC.UMN.EDU!slevy
From: sl...@UC.MSC.UMN.EDU ("Stuart Levy")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: password aging (from worm discussion)
Message-ID: <8811181630.AA10668@uc.msc.umn.edu>
Date: 18 Nov 88 15:30:41 GMT
Sender: use...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 20
> From: Barry Shein <encore!pinocchio!...@talcott.harvard.edu>
> Although I support the other proposals I will argue that shadow
> password files are a bad idea ...
> It means that if, for any reason, you believe your password file has
> been let out you will have to admit that your security is compromised
> and, for starters, have everyone change their password ...
> You're turning the file into pure gold.
I don't understand this, could you explain further? Shadow password
files aren't intended to contain clear passwords, they'd hold encrypted
ones just as they do now. Using them would just impede people from casually
picking up the file and trying passwords without going through login etc.
But even if someone did capture a copy of a shadow pw file, you'd only be
in the same situation you always were when /etc/passwd contained passwds.
So is it really the kind of catastrophe you suggest?
Stuart Levy
Path: utzoo!utgpu!watmath!clyde!att!ucbvax!pinocchio.UUCP!bzs
From: b...@pinocchio.UUCP (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: password aging (from worm discussion)
Message-ID: <8811181901.AA12769@pinocchio.UUCP>
Date: 18 Nov 88 19:01:52 GMT
References: <8811181630.AA10668@uc.msc.umn.edu>
Sender: use...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38
>> You're turning the file into pure gold.
>
>I don't understand this, could you explain further? Shadow password
>files aren't intended to contain clear passwords, they'd hold encrypted
>ones just as they do now. Using them would just impede people from casually
>picking up the file and trying passwords without going through login etc.
>But even if someone did capture a copy of a shadow pw file, you'd only be
>in the same situation you always were when /etc/passwd contained passwds.
>So is it really the kind of catastrophe you suggest?
>
> Stuart Levy
That's the idealized situation. In reality once you've decided that
the security of your system depends on the read security of one file
then any breech of that must be responded to, common sense would
dictate it. Otherwise, why did you make it unreadable? I don't think
going forth with the idea "oh, we did it, but we never *really* needed
to, it doesn't matter if a copy got out" is a rational approach.
Otherwise one is just trying to have it both ways, relying on the
security of an unreadable pw file but saying you don't really care if
anyone reads it. At that point at best it's a matter of whether you
can sell such an attitude to your (management? users?) when they come
to you and say "gee, I saw so and so walk out with a listing of the
password file...what are you going to do?"
Don't think about yourself who knew in November 1988 *why* you went to
shadow pw files, think about (oh) 5 years from now when every system
is delivered and manuals say to keep the pw file unreadable because
otherwise passwords might be cracked.
I still contend it's a bad idea, concentrate on the other aspects.
If some form of publicly readable encryption is deemed impossible
as a concept I sincerely hope that argument gets published.
-Barry Shein, ||Encore||
Path: utzoo!attcan!uunet!husc6!mailrus!ames!joyce!distek4!mckenney
From: mcken...@distek4.uucp (Paul E. McKenney)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: password aging (from worm discussion)
Message-ID: <15005@joyce.istc.sri.com>
Date: 21 Nov 88 19:43:53 GMT
References: <8811181630.AA10668@uc.msc.umn.edu> <8811181901.AA12769@pinocchio.UUCP>
Sender: nob...@joyce.istc.sri.com
Reply-To: mcken...@distek4.UUCP (Paul E. McKenney)
Organization: SRI International, Menlo Park CA
Lines: 56
In article <8811181901.AA12...@pinocchio.UUCP> b...@pinocchio.UUCP
(Barry Shein) writes (in regard to shadow password files):
>>> You're turning the file into pure gold.
>> [ . . . ]
>>But even if someone did capture a copy of a shadow pw file, you'd only be
>>in the same situation you always were when /etc/passwd contained passwds.
>>So is it really the kind of catastrophe you suggest?
>> Stuart Levy
>That's the idealized situation. In reality once you've decided that
>the security of your system depends on the read security of one file
>then any breech of that must be responded to, common sense would
>dictate it. Otherwise, why did you make it unreadable? I don't think
>going forth with the idea "oh, we did it, but we never *really* needed
>to, it doesn't matter if a copy got out" is a rational approach.
> [ . . . ]
>I still contend it's a bad idea, concentrate on the other aspects.
>If some form of publicly readable encryption is deemed impossible
>as a concept I sincerely hope that argument gets published.
> -Barry Shein, ||Encore||
World-readable encrypted passwords allow an attacker to verify that he
has correctly guessed a particular password, and to perform this verification
on a host other than the one being attacked.
This will allow the attacker to crack a significant fraction of the
passwords (I have seen claims that over 30% of passwords are easily
guessed) without leaving any traces of his attack, aside from a single
(possibly legitimate) access to the system using the privileges of a
normal user. Even if all passwords are well-chosen, the attacker has
a non-zero chance of guessing a given password. If the attacker has
enough fast hardware at his disposal, he may in fact have a pretty
good chance. And there is always the chance that someone might come
up with a clever attack on DES . . .
Given a properly implemented and configured shadow password file, the attacker
must have privileged access to the machine to get the encrypted passwords
(assuming that all people that -do- have such know not to release the
encrypted passwords). The attacker can of course use the target host's
own login prompt to verify guesses at passwords, but this sort of activity
should alert the host's administrators.
If someone who does not have legitimate privileged access to the machine
is seen with a list of the encrypted passwords, it can be assumed that the
host's (network's) security has been compromised, and appropriate steps
can be taken.
It is still a good idea to encrypt the passwords (rather than relying solely
on the filesystem permissions) in order to reduce vulnerability to the
infamous ``disgruntled employee'' security hole.
In short, the idea behind shadow password files is to make it at least as
difficult to crack a password as it is to crack the system itself.
This is an especially good idea for machines that have a password for
the user ``root''.
Thanx, Paul