🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.crypt
Article #4273

Re: Yet Another useful paper

#4273
From: Barry Shein
Date: Fri, 23 Dec 1988 18:02
48 lines
3023 bytes
From: henry@utzoo.uucp (Henry Spencer)
>In article <12750@bellcore.bellcore.com> karn@ka9q.bellcore.com (Phil Karn) writes:
>>I too have my doubts about the effectiveness of shadow password files.  My
>>fear is that it will make administrators complacent; they'll reason that
>>since no one can get at the file, then there's no need to ensure on a
>>regular basis that people pick hard-to-guess passwords.
>
>Turn it around:  would you suggest deleting shadow password files, from
>systems which already have them, just to keep the sysadmins alert?

Although I agree with Phil Karn I also agree with Henry that this
reasoning is not compelling.

I tend towards the concern that if password files are made unreadable
then we admit system security demands their unreadability. Given that
we create the situation where if there's any suspicion that the pw
file has gotten out we have to admit a security crises.

For example, discovering a software bug which allowed any file to be
read by any user, I know of a few in many systems (they've been
discussed in the recent past, no secrets here.)

Right now that would be a major concern on some systems, minor on
others (eg. a system where all files are readable anyhow, not terribly
uncommon, or of no great consequence.)

By moving to shadow password files there's no choice, any bug which
permits reading of unreadable files must be admitted to be a major
security breach. Perhaps on your (universal "your") system you can
tell your management and users that it really doesn't matter if every
disgruntled employee now has a copy of the pw file but that sort of
complacency can't be counted on.

To turn it around, if you find a bug which allows anyone WRITE access
to any file on the system don't you immediately check the password
file? Unfortunately read access is more insidious since you probably
can't tell if the pw file has been read by an unauthorized user, and
it requires no tracks (that is, I can check the pw file against a
recent backup tape after a write breach, after a read breach there's
no modification to compare for.)

Or do we conclude that we'll make the pw files unreadable but not be
concerned if they happen to get read?

I claim it's a can of worms being created.

	-Barry Shein, ||Encore||
Technical Details
Message-ID: <4470@xenna.Encore.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!ucbvax!husc6!bu-cs!encore!bzs
References: <11013@ulysses.homer.nj.att.com> <2308@cuuxb.ATT.COM> <4420@xenna.Encore.COM> <2743@epimass.EPI.COM> <110@microsoft.UUCP> <12750@bellcore.bellcore.com> <1988Dec21.194132.17986@utzoo.uucp>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!ucsdhub!sdcsvax!ucsd!ucbvax!husc6!bu-cs!encore!bzs
From: bzs@Encore.COM (Barry Shein)
Newsgroups: sci.crypt,comp.unix.wizards,news.sysadmin
Subject: Re: Yet Another useful paper
Message-ID: <4470@xenna.Encore.COM>
Date: 23 Dec 88 18:02:50 GMT
References: <11013@ulysses.homer.nj.att.com> <2308@cuuxb.ATT.COM> <4420@xenna.Encore.COM> <2743@epimass.EPI.COM> <110@microsoft.UUCP> <12750@bellcore.bellcore.com> <1988Dec21.194132.17986@utzoo.uucp>
Organization: Encore Computer Corp, Marlboro, MA
Lines: 48
In-reply-to: henry@utzoo.uucp's message of 21 Dec 88 19:41:32 GMT
Posting-Front-End: GNU Emacs 18.41.15 of Tue Jun  9 1987 on xenna (berkeley-unix)