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

[Terri Oda]

On Dec 15, 2004, at 11:37 AM, John Dennis wrote:

> This was forwarded to me by our security officer. I believe the 
> original
> author, Florian Weimer, intended to reach this list but did not know 
> how
> to and instead went through his security contacts. Perhaps Florian's
> concerns would best be addressed in MM 3.0 and maybe this should be
> added to the MM 3.0 feature list. BTW, is there an independent MM 3.0
> list? I thought I had heard such a beast existed, but my recollection 
> is
> hazy.

The list for 3.0 is http://mail.python.org/mailman/listinfo/mailman3-dev

More information can also be found on the wiki 
http://zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage

First off -- as far as I know, the mailman password generation 
algorithm was never intended for significant security.  It was intended 
to generate nearly-pronouncable (and thus easier to remember) passwords 
as a mild deterrent to attackers.   I wouldn't really characterize this 
is a security bug so much as a design choice that you may or may not 
agree with.

I'm not sure it makes sense to worry about the auto-generated passwords 
when we're plaintexting them (and any archive data, and any email) 
across the Internet.  If you're storing sensitive archives in Mailman 
you should probably be looking at something beyond Mailman for 
security, including an https server.  Perhaps a short term fix would be 
to double-authenticate somehow.

 >The idea of storing sensitive data in Mailman archives
 >seems to be a bit crazy, but unfortunately, it is common practice.

The idea of sending sensitive data *by unencrypted email* is a bit 
crazy.  Doesn't mean it's not done, but I don't want to spend a whole 
lot of time designing a more secure mailman only to have people 
complain that their email still isn't secure.  If you're really storing 
sensitive documents, maybe you need to look at some PGP extensions to 
Mailman as well...

Despite these considerations that make the whole idea more complex, it 
might be worth looking at some secure mailman options for 3.0 (assuming 
you've got a certified https server and all that jazz), and 
incorporating some of these suggestions for their other benefits (eg: 
disallowing user-selected passwords means people can't accidentally use 
trusted passwords for mailing lists).  But we're going to have to do a 
lot more thinking and designing if we want to claim that Mailman's safe 
for sensitive documents.

  Terri