Re: crypt() MD5 etc.. (was something else.

[morgan physics ucla edu (Andrew Morgan)]

Marek Michalkiewicz wrote:
> 
> Andrew Morgan:
> > At some point in the distant future, a sys-admin is going to want to
> > "turn off" an insecure DES based crypt() in favor of something better?
> 
> Quite possible.
> 
> > 	1. add a flag to the all-scheme-knowing pam_unix module
> > 	   indicating which encryptions are permitted.
> > 
> > 	2. have separate modules that will do similar things (but with
> > 	   different encryption algorithms) pam_unix, pam_unix_md5,
> > 	   etc..
> 
> 3. The module permits all algorithms, but uses a specified one by
> default for new passwords (the salt string for crypt() is generated

This is really what I intended for 1. except the sysadmin has some
control over which old passwords are still permitted (this is going to
be required if some scheme one day becomes completely insecure)

> New crypt() algorithms aren't being broken _that_ often, the DES
> based one was good for some 20 years...

The point is that new crypt() algorithms *are* being invented more
often and given that new passwords are encrypted using only one of
these, it seems insecure to leave little used passwords hanging around
like a weak backdoor entry for some intruder.

There is also the question of modifying working code when trying out a
new authentication method, which is not always a good thing.

> We may end up with too many similar modules - especially if (as it
> has been suggested before) there are separate shadow and non-shadow
> modules (so you now get twice as many of them).  I hope not...

The reality is that there is only going to be one module source
tree--so both 1. 2. (and 3.) will probably be possible at the same
time. Just as shadow support is currently turned on with compile-time
options, various encryption schemes will be optionally compiled into
the pam_unix module. I guess my personal suggested policy for
sys-admins will be to recompile the module with individual schemes and
rename it appropriately... And others will have other
suggestions---this is part of the freedom/flexibility of PAM.

This is not really something we should waste energy arguing about!

Regards

Andrew