[support] Password in clear text

[Richard Damon]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20121202/1f9f0c95/attachment.html