Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hc!beta!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: sci.crypt
Subject: Re: Unix Password Security
Message-ID: <7338@brl-smoke.ARPA>
Date: 24 Feb 88 15:02:21 GMT
References: <7271@brl-smoke.ARPA> <5289@well.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes:
>Ok, one fix would be to keep the encrypted passwords in a non-world-readable
>file, while leaving the rest of /etc/passwd readable so that nothing breaks.
>Doing this would mean adding a small hack to the getpwent routines, and
>recompiling login and passwd.  But if you don't have source, this is a
>problem.

Since you wouldn't be changing the format of /etc/passwd, just its use,
no hack to getpwent() is necessary.  Of course the real authentication
agents such as login and passwd do have to understand the new scheme.
They're easy enough to write from scratch, as you suggested.  (Actually,
so is getpwent(), but as I said that's unnecessary.)

Trying to cripple the encryption so that it runs very slowly is not
adequate.  A cracker could simply copy your /etc/passwd to a fast
machine and crack it there.  To be confident that this would take too
much time for the cracker, assuming your system isn't a Cray or
equivalent, you'd have to slow down the algorithm so much that logging
into your system would take intolerably long.

by the way, once you have the separate password file method working,
it might be fun to generate random passwords and fill /etc/passwd with
their encryptions.  That way a cracker who doesn't know that your
system uses a better method could waste a lot of his time attempting
to crack and use the fake passwords!