Re[2]: [Mailman-Developers] Big checkins a'comin'!

[John Morton]

On Wed, 14 Feb 2001 22:59:15 -0500 Barry A. Warsaw <barry@digicool.com> wro=
te:

>=20
> >>>>> "JM" =3D=3D John Morton <jwm@plain.co.nz> writes:
>=20
>     JM> Might as well add code to convert the password from the
>     JM> depreciated form to the current default if one of the fallback
>     JM> methods succeeds, then set the fallbacks to cascade over
>     JM> crypt, MD5 and plaintext. This way, you can quitely change to
>     JM> a more trusted hash should your current default eventually be
>     JM> broken.
>=20
> No can do.  crypt()'s a one-way hash and Mailman doesn't store the
> cleartext password (for the list), so there's no way to recover it in
> order to convert.

Indeed - that's why I was talking about doing it when one of the fallback
methods for authenicating the password succeeds. The list admin has just
supplied you with a password, and you know it's correct because you've
just successfully compared the crypted version (or whatever) with the one
stored. Might as well take the default hash of the password and store that
at the same time.

> I've thought about storing the list password in the clear.  This would
> allow a mail-back option for list owners, but requires for stricter
> security in the file system (since the list passwords can be snooped
> from the database).

Have the site administrator make the call by allowing them to set the
default password storage method themselves, and if it happens to be set
to plain text, have the mail-back option available. This might require
tagging the passwords with their method of encoding, but it should be
possible to convert existing passwords without too much trouble.

Of course, the documentation should recommend SHA-1 is (probably) better
than MD5, which is better than crypt, and that a plaintext password
installation should take special care to protect the mailman install from
snooping.

John