> 
> What about modifying the programs which do login-related password checking
> to use an intermediate interface, such that crypt() itself did not have to
> be replaced, but rather the "intermediate interface" could be re-written
> to use another crypt-like function?

this requires modifying every single program that does user authentication.

> For example, I do not like the idea that login(1) must know about what
> particular encryption algorithm I am using, and how I store it in the
> password field.  I feel that the function "pwcheck" (login.c, line 433)
> or something like it should be available to all such login-type programs...
> ftpd, etc.  Implementation of the encryption algorithm probably shouldn't
> be hard-coded into these programs.  It makes me shiver to see them
> assume that you grab the first n letters from the encrypted password,
> and the next n+1...m letters, and do a crypt with part of it, and strcmp...

The authentication is not hard coded into the login program.  crypt()
can be replaced with any module that takes two arguments which are
the user entered response to the password prompt and the password entry
in the password file and returns a string suitable for the password
file.

The athentication method is somewhat hard-coded into the passwd
program in that it must know the format of the salt.

> Perhaps a libauth.a or auth.h or something is in order?  You could then put
> all the "knowledge" of the authentication mechanisms in there, and do all the
> #ifdef DES or #ifdef MD5 or #ifdef SHA's that you want.  And stuff that needs
> crypt() won't break.  And you can play with different (new) algorithms, etc.
> Or you can just keep it the way it is and use a compatible crypt.

This is already the case.  This is where any changes to the crypt (hash)
function would be placed.

> Only problems I can see are:
>     (1) modifying existing sources in the distribution to use the new calls
>     (2) catching non-distribution programs that rely on the exact implement'n
> of the password mechanism.  For example, "screen"s locking feature locks your
> screen with your login-password.  I assume NIS and other things fall into
> this category.

If they call the function properly then this sould work.  All programs
that behave as:

     guess = users supplied password string;
     pwentry = password field from password file
     res = crypt(guess, pwentry);
     if(strcmp(res, pwentry) == 0) then success

will work fine even if the crypt(3) function is replaced with some
other function.

> I would enjoy implementing some of these algorithms for the distribution.
> I've been itching for a reason to work on crypto stuff since I read Schneier's
> book :)
> -- 
> VaX#n8 (vak-sa-nate) - n, CS senior++ and Unix junkie - vax@ccwf.cc.utexas.edu
> Just the vax-man.  Read my MIPS, no new VAXes!        - PGP key on request