> 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.

Actually, I have a crypt(3) that works fine for both, by looking at the
salt string.  If it matches the format of the DES-style hashed
passwords (13-character base-64, or _ plus 19-character base-64), or
the salts typically used with them (two-character base-64, or _ plus
8-character base-64), it calls des_crypt, which may or may not exist
(well, may or may not be functional) depending on whether you have a
USA-exportable system.  But if the salt string is anything else, it
calls md5_crypt, which understands its own hashed password format and
can live with anything.  crypt_makesalt() is provided to generate a
salt string appropriate for getting the latest and greatest password
hash out of crypt().

Thus, to check a password the canonical incantation is
	strcmp(crypt(clearpw,pw->pw_passwd),pw->pw_passwd)
which works regardless of what sort of password it is (working
des_crypt required for DES-hashed passwords, of course).  To set a
password, one does
	crypt(clearpw,crypt_makesalt())
for a local password, or generates a salt string by hand and calls
	crypt(clearpw,salt)
if one wants one of the old styles - which is what old programs did
anyway, so it continues to work.  (Again, working des_crypt required
for old DES-style passwords.)

>> 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.

Well, crypt(3) doesn't do encryption of files.  crypt(1) and ed -x use
crypt(3) to hash the key before using it to set the rotor state, so
yes, it has to be compatible, but it's not used directly for
encryption; any one-way function could work there, though to avoid
rewriting pieces of crypt(1) and ed(1), it would have to have the same
interface (same salt string format in, same alphbet out, etc).  Which
is what I've done.

I have a replacement lib/libcrypt and a couple of small patches to
usr.bin/passwd, which I'm going to toss out on current-users for
criticism soon.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu