[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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
differently depending which algorithm should be used).  Change the
default, and force all users whose passwords are encrypted using
the old algorithm to change their passwords (you would have to do it
anyway - by disallowing the use of this algorithm, you effectively
lock their accounts until they are assigned new passwords).

> of course no-one will want to use it, and consequently it should not
> be on any system!

If no users have passwords encrypted using the old (now insecure)
algorithms anymore, there is no danger in still permitting them.
New crypt() algorithms aren't being broken _that_ often, the DES
based one was good for some 20 years...

> [Note, there will obviously have to be a new password service module
> for each flavor of encryption.]

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...
If most of the module code is similar, and there are only a few
small differences, just one module accepting different configuration
options looks like the correct solution to me.

Comments?

Marek



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []