Password security - Another idea

[The Beach Bum]

In article <11056 at ulysses.homer.nj.att.com> smb at ulysses.homer.nj.att.com (Steven M. Bellovin) writes:
>In article <2803 at cbnews.ATT.COM>, res at 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.

Agreed.  The encrypted password should not be made available, and the
encryption method should be selectable from a variety of methods, or
the internal key [ constant portion ] should be readily modifiable.

Let's not make things any easier than need be.

On the similiar vein - It would appear that AT&T is playing with a new
version of shadow passwords with yet another file layout.  This version
includes password expiration warning information and login administration
fields in one big mess of an entry in a completely new file -
/etc/privates.

There is a command - rdpriv - which provides user access to the privates
file, but does not return the user's encrypted password, only the
password aging information.  This now leaves us with three completely
incompatible formats in the USG universe ...
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Anything on the road which can be
InterNet: jfh at rpp386.Dallas.TX.US       | hit, will be ..."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------