Subject: Re: crypt(3)
To: None <email@example.com>
From: VaX#n8 <firstname.lastname@example.org>
Date: 11/17/1994 20:34:47
While really really bored, Greg A. Woods wrote:
> But that's not really the problem. The problem around here is that we
> need portability of the encrypted data to older implementations, not
> portability of the interface.
Oh, perhaps I didn't make myself clear; I meant that you could define
this interface for local user authentication (only). That way, you
-never- worry about all the other programs which rely on crypt(3)
to work the same way. For example, if you play a game which stores its
passwords or magic phrases in crypted format, you don't want it to break.
And you certainly don't want "telnet -x" and other things to break.
If it suddenly started using SHA, it would be "broken", too!
This addresses the point in your following paragraphs.
In short; you are defining an interface for authentication relative to the
local, unshared, password file, in the same way that the getpw* routines
defined an interface to the entries themselves (rather than reading the raw
file). I think that this kind of encapsulation is pretty good in and of itself.
I think that not making a distinction between local authentication and
networked-NIS-type-stuff will probably end up being a problem for the same
reasons that directly grokking the /etc/passwd file is bad and had to be
stopped when we started using shadowed passwds and the 10-field master.passwd
format. The sol'n is one set of funcalls for local
use, and another for distributed use, and if they end up both calling crypt
or the local one calls sha_crypt() and the distributed one calls crypt(),
nothing gets hurt. Sorry if I am being too verbose :)
> In an isolated environment, any encryption function could be substituted
> for any of the uses of crypt(3), esp. password encryption.
> However, crypt(3) input/output must remain compatible for files
> encrypted with any utilities that do so, such as ed(1), and for password
> entries in the case where these entries may be shared.
VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - email@example.com
Just the vax-man. Read my MIPS, no new VAXes! - PGP key on request