Path: utzoo!attcan!uunet!husc6!rutgers!gatech!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.unix.wizards
Subject: Re: Password security - Another idea
Message-ID: <11056@ulysses.homer.nj.att.com>
Date: 3 Jan 89 02:51:55 GMT
References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <4537@xenna.Encore.COM> <2803@cbnews.ATT.COM>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 29

In article <2803@cbnews.ATT.COM>, res@cbnews.ATT.COM (Robert E. Stampfli) writes:
> Can anyone think of a good reason why either of the following should not be
> done on systems that employ a shadow password file:
> 
> 1. Provide a program which returns the encrypted version of the password
>    for the uid (or euid) that invokes it.

I see no reason to make this available; provide a server which checks
for a match instead.

> 2. Provide a program, similar to "passwd", which modifies the encrypted
>    password in the /etc/passwd file, like the original version of the
>    passwd command did.
> 
> Both if these, it would seem to me, would be useful in writing things like
> terminal lock programs (case 1),

terminal lock programs are a great way for me to break into your account.

> or programs that run set-uid to one account
> to allow users the ability to do something with files owned by that account,
> provided they possess the "public" password (case 2).

in which case I may just crack on your ``public'' password.  Besides,
if I need that I can implement my own file which will be private as well,
and even allow me to have different ``public passwords'' for different
users.  I don't see the benefit of a system-level version.  And if your
setuid program that lets me ``do something'' to your files isn't good
enough....