Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!amelia!prandtl.nas.nasa.gov!msf
From: msf@prandtl.nas.nasa.gov (Michael S. Fischbein)
Newsgroups: comp.unix.wizards
Subject: Re: Password security - Another idea
Message-ID: <1321@amelia.nas.nasa.gov>
Date: 6 Jan 89 22:59:54 GMT
References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <4537@xenna.Encore.COM> <654@white.gcm> <2629@ficc.uu.net>
Sender: news@amelia.nas.nasa.gov
Reply-To: msf@prandtl.nas.nasa.gov (Michael S. Fischbein)
Organization: NASA Ames Research Center
Lines: 37

In article <2629@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <654@white.gcm>, dc@gcm (Dave Caswell) writes:
>> If people have no reason to look at encrypted passowrds and it is easy to make
>> sure they can't look, why not have hidden passwords?
>
>Because open passwords let users write utility programs that verify who you
>are.  If the password file is hidden, you need to provide a password
>verification server.

And, if you want compatability with the programs already written and
those to be written with a view towards the existing documentation, you
provide compatability with the getpwent(3) routines, and access to the
encrypted passwords is trivial.

Thus, to have a shadow passwd file you give up a significant amount of
com- patability with existing documented routines.  Perhaps making the
crypt(3) call have some knowledge of the number of times it has been
recently called and having it slow down would help.  This requires the
system's encryption routine to be publicly unknown, of course,
otherwise the algorithm could simply be reimplemented more quickly.
Rewriting crypt(3)  would lose for people setting up new systems and
trying to transfer passwords from old ones; a much rarer situation than
trying to port programs.

I'd guess the tradeoff involves how much non-vendor supplied (not just
freeware) software you use that requires password verification, what
sort of attacks you anticipate on the system, and how much effort you
can put into customizing stuff.

		mike



Michael Fischbein                 msf@prandtl.nas.nasa.gov
                                  ...!seismo!decuac!csmunix!icase!msf
These are my opinions and not necessarily official views of any
organization.