On 12/2/12 12:24 PM, Pat Ferrel wrote:

Wow, this is complete foolishness.

How does my failure to read a notice have anything to do with an obviously bad practice? Red herring!

Also what does the fact that this is a community effort have anything to do with an obviously bad practice? Another red herring. Community can also work to point out failures like this and work to fix them.

The password protects low security information but I am not even sure where else I use that password. And this itself is another red herring.

Passwords in clear text are universally and absolutely BAD. You can justify the fact that no one has time to fix it. That I understand but the rest of these arguments are purely specious.

Then I presume that you only use https (and never http) to access web sites, sftp (and never ftp) to send data, and use SSL to fetch your email, and only use sites that support these with keys you know you can trust.

Using the same password on multiple sites is a bigger mistake than sending passwords in clear text, as you are then trusting the security of the sites you share passwords to the worse security of any of them. If you didn't notice the clearly stated policy of sending your password in clear text with an explicit warning not to use a valuable password, how much do you check on the password security of the other sites you use. Many sites do not store your password encrypted, or may have holes that allow someone to steal your password while accessing the site.

Mailman was designed over a decade ago (I guess that makes your previous comment about last century true), and as part of its design goals, it is to be fully utilized by a user using only email traffic. With this as a design parameter it is IMPOSSIBLE to not send a password in clear text without requiring extensions beyond basic email, as email is a non-encrypted. While the web interface has become more powerful, and thus perhaps now the primary access channel for options, it wasn't so in the beginning, (you can subscribe by sending and email, change your options with another email, etc). For all of these email transactions the password needs to be sent in the clear, so securing the web access better doesn't make that much sense. Think how you would do a "password reset" function like Drupal uses via a pure email transaction that doesn't send the password in clear text.

Note also that if your email system has been compromised enough that someone can read your email to find the password, they likely also have the ability to do a password reset on a web site and get control over your account there, so the added security is mostly imaginary, IF you are careful to keep you local machine secure (and if you don't do that, it is a bigger problem than clear text passwords).

Yes, there are some security implications of passwords in clear text, and for web based services there are methods that improve things. There ARE some fundamental issues that make totally fixing it hard, to the level that some say the only way to really improve the security of email is to totally dismantle the system and rebuild it. The fact that you are on this list lets me assume that you are not of the position that we should throw the existing email system away until we can get something better.

As to not having time, there are several projects going on to build better email list managers, but for now, I don't know of any free/open-source solutions with the reliability of Mailman that does NOT use plain text passwords (actually you would be hard pressed to find an open-source solution that seriously challenges Mailman even with plain text passwords). YOU have the choice, use the system with it's inherent warts, or don't use the system (or put in your time to make the system better).

Security ALWAYS starts at the user, and to complain that something is "universally and absolutely BAD", when that behavior is CLEARLY stated on the page you are using to sign up for the service says the real security flaw is on your end.

-- 
Richard Damon