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?

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

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.

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.

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