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

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

Marek Michalkiewicz wrote:
> $1$salt$encrypted
> where:
> $1$ - magic to recognize this algorithm
> salt - 1 to 8 characters of the salt string
> encrypted - exactly 22 characters (128 bits, base64 conversion)
>  of the MD5 hash proper (after many iterations, to slow things down)

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?

There are two logical ways to do this

	1. add a flag to the all-scheme-knowing pam_unix module
	   indicating which encryptions are permitted.

	eg. /etc/pam.conf line

	  login auth	required	pam_unix shadow md5 ripemd160 sha

	2. have separate modules that will do similar things (but with
	   different encryption algorithms) pam_unix, pam_unix_md5,

	eg. /etc/pam.conf lines

	  login auth	sufficient	pam_unix_md5 shadow
	  login auth	sufficient	pam_unix_ripemd160 shadow
	  login auth	sufficient	pam_unix_sha shadow

	[each module checks to see if the $1$ -magic prefix is the one
	it likes, failing otherwise, and passing control to the next

I'd like to argue that 2. is the better choice, and more consistent
with the PAM model.

With case 1, there is a simple problem that will become evident in
time: the pam_unix.so module will eventually get huge. Like a modern
modem which despite being 28.8 still needs to be able to talk to 300
baud dinosaurs, the pam_unix module will be required to know about
crypt() long after the typical TV remote control has enough computer
power to search the entire key space in less than the amount of time
it takes to decide the channel you are watching is really
uninteresting (forgive the hyperbole, but you get the idea). By then
of course no-one will want to use it, and consequently it should not
be on any system!

With case 2., the sys-admin, can add (and debug) new modules and
*delete* old (and insecure) modules as it becomes desirable---not
having to rebuild or modify working code. After all, this was why PAM
was suggested in the first place.

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




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