On Wed, Nov 2, 2011 at 6:00 AM, Stephen J. Turnbull <step...@xemacs.org> wrote:
> Jeffrey Walton writes:
>
> > The best I can tell, Mailman 2 did the wrong thing.
>
> Against what threats with what level of security do you have in mind?
I found it interesting you brought a threat model into the discussion.
The best I can tell, the Mailman threat model is naive or unrealistic.
There are at least three threats which should be modeled. First is
unknown attackers who are breaking into systems and harvesting {user
name, email. password} tuples. As a user, I got nailed when GNU's
Savannah was hacked.
I reused a password (bad dog!), and the bad guys broke into an
unrelated gmail account. That is, the attackers got {Jeffrey Walton,
noloader/gmail.com, XXXX} from Savannah and used it to successfully
compromise jeffrey.w.walton/gmail.com due to password reuse. They
could not get noloader/gmail access, or banking access since the
passwords are different.
The second threat is the system administrator. I understand a sysadmin
must be trusted, but why is he or she trusted so much that they are
entitled to plain text passwords?
The third threat is government. Any government can compel a list
administrator to give up his or her {user name/email/password} list
*if* the list operated within its jurisdiction. The government - as an
adversary - can surreptitiously do the same things an attacker can do.
In the US, the PATRIOT Act assures these things (full database access
and the ability to act surreptitiously without oversight).
These are not theoretical threats. They happen in practice, and happen
too frequently.
> > Confer: list managers did not fix Mailman 2 (nor did they use other
> > software which was secure). Why would you expect them to research
> > and securely configure Mailman 3?
>
> I don't expect them to do so, until they get embarrassed (or worse)
> for not doing so. What else is new?
>
> Security inherently requires research and configuration. Asking for
> "secure out of the box" is meaningless; it's what happens after it
> comes out of the box that matters.
Storing a salted hash is an accepted best practice. It should not
require research nor configuration by the list manager.
Another example: MD5 was compromised in the mid-1990s, and its
security has only gotten worse over time. MD5 is not even close to its
theoretical security level of 2^64. If a program uses a hash for
security related functions, MD5 should not be used (some hand
waiving).
So to answer the security level question: store a salted hash of the
password using SHA-224/256 or Whirlpool. The use of SHA-2 or Whirlpool
stems from NIST [1,2] and ECRYPT [3] recommendations on algorithm
strengths. With a salted hash (using an appropriate hash function),
list managers don't need to do any research or configurations, and I
don't have to worry about hackers, system administrators, or most
government attacks.
Finally, it makes more sense to fix the problem in one place (Mailman
source code, by the Mailman developers) rather than 10,000 places
(each Mailman installation, by every Mailman list manager).
Jeff
[1]
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf
[2] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
[3] www.ecrypt.eu.org/documents/D.SPA.7.pdf
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
