[Systers-dev] Fwd: Fwd: [Mailman-Users] [Mailman-Developers] openID enabled mailman

[Malveeka Tewari]

---------- Forwarded message ----------
From: Sarah Mei <sarahmei at gmail.com>
Date: Mon, Jun 15, 2009 at 2:15 AM
Subject: Re: [Systers-dev] Fwd: [Mailman-Users] [Mailman-Developers] openID
enabled mailman
To: Malveeka Tewari <malveeka at gmail.com>, Jennifer Redman <jenred at gmail.com>,
systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>


I agree with Stephen. The best way to use the Mailman
usernames/passwords as OpenID info is to

a) Set up a separate, standalone OpenID provider.
b) Import the Mailman data into the OpenID provider's database.
c) Patch Mailman to accept only that OpenID provider as its
authentication system.
d) Have users change their passwords by mailing them a link to
password reset (which will gradually eliminate the insecure passwords
from the system).

Ultimately, if the single sign-on is to be useful, it has to be built
on a foundation more secure than Mailman passwords. When we're just
talking about a mailing list, cleartext passwords are fine, because
even if a non-Syster gets ahold of it, s/he can't do anything except
read the archives, and change the Syster from digest to non-digest. :)

But when we're talking about using other services with this, the
passwords become more valuable and merit at least basic security.

Is there some way I can assist with this? I'd be happy to do so.

Sarah

On Sat, Jun 13, 2009 at 7:06 AM, Malveeka Tewari<malveeka at gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Stephen J. Turnbull <stephen at xemacs.org>
> Date: Sat, Jun 13, 2009 at 1:37 PM
> Subject: Re: [Mailman-Users] [Mailman-Developers] openID enabled mailman
> To: Malveeka Tewari <malveeka at gmail.com>
> Cc: Mailman-Developers at python.org, mailman-users at python.org
>
>
> Malveeka Tewari writes:
>
>  > Our focus is on providing Single Sign On but we do not want to delegate
>  > authentication to a third party. Hence we want to implement OpenID
> provider
>  > for our Mailman service.
>
> I don't think this is a good idea.  Mailman is designed to deliver
> single messages to multiple parties, which it does very well, and to
> manage member lists, which it does tolerably well for many purposes.
> It is not designed to keep secrets.  You may not now particularly
> care, but it could be very annoying later if you decide you want more
> security and need to switch your system.
>
> Better to put your provider in a separate place from Mailman, and have
> Mailman rely on and trust only your provider.  You could do them on
> the same host if necessary but in the long run you might want to have
> the provider on a dedicated host, depending on how serious you become
> about security.
>
>  > and OpenID relying partyOD for our wiki etc.
>  >
>  > Now for the OpenID provider we may choose to have new passwords or use
> the
>  > mailman passwords. For ease of users, we want to use the mailman
> passwords
>  > for the OpenID provider.
>
> Again, Mailman is not very secure.  In the default configuration,
> passwords are mailed out in cleartext over non-secure channels (and
> even so-called secure mail is pretty tricky -- it's much easier to
> secure a web application).  The passwords are also stored in the
> clear.  This means that if you want to set up OpenID for existing
> users by transferring their passwords, it should be possible (I don't
> know how offhand, though).
>
> I don't recommend that, either.  Normally, people don't care that much
> as there's not much damage that can be done via a mailing list, except
> spamming, and most lists have additional defenses against that.  But
> you plan to rely on these passwords to secure multiple services,
> making the value of cracking one that much higher.  I would ask my own
> users to set new passwords in this situation.
>
> Of course, all these issues depend on a lot of factors.  You may have
> better security than the default for the Internet in place, or much
> more careful users, etc.