[Mailman-Developers] [Fwd: [vendor-sec] Weak auto-generated passwords in Mailman]

Barry Warsaw barry at python.org
Wed Dec 22 23:49:28 CET 2004


So let me try to address some of the issues raised here.  There's two
things: what we can do for Mailman 2.1, and what we can do for Mailman
3.0 (yes, it is still alive ;).

For the most part, passwords are one big PITA all around.  I'd love to
see mechanisms in MM3 that would eliminate passwords altogether.  I
don't know if that's possible, but one option might be to drop cookies
after completing a web-based confirmation, or possibly pubkey based
authentication for email communications.  There needs to be /a lot/ of
thought into this, including issues of usability vs. security, and what
level of security we actually want to assert.

For MM2.1, we long ago did a risk assessment on the assets that the
password protects and we decided on the current scheme based on the
value of those assets, which we deemed to be fairly low.  I still think
that's true except perhaps for private archives.  Understand also that
the bundled archiver, called Pipermail, was never intended to be
ultimately secure, nor for that matter, highly scalable, robust, etc. 
Its primary use case was for public mailing lists, and to provide zero
effort archiving.

So my standard answer if you don't like Pipermail is, use some other
archiver.  They are easy to integrate with Mailman.  I know that a
number of large sites are doing this.

The question is, outside of private Pipermail archives, do you feel that
the user friendly, but not very secure passwords are adequate given the
value of the asset they protect?  We certainly felt they were when we
designed the current system (which includes all the other ways to crack
the password, including plaintext password reminders and storage of
plaintext passwords in config.pck file).

BTW, I believe Python 2.4 has an interface to /dev/urandom, and we could
certainly add some optional support for more cryptographically secure
password generation for Mailman 2.1.  It should not be the default
because I don't believe the majority of users would benefit from more
secure but less user friendly passwords.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041222/c0a8dd32/attachment.pgp


More information about the Mailman-Developers mailing list