[Systers-dev] Considering LDAP and OpenID

Sat May 30 08:41:02 PDT 2009

We can eliminate the monthly mailing, but it doesn't solve the problem --
the password is still being sent in cleartext through the mail.  But perhaps
if we restrict its use to just systers related sites, that isn't a security
compromise (or more of a security compromise than we have now). They won't
be using for their bank accounts or their email, etc.
Robin

On Fri, May 29, 2009 at 6:22 AM, P. A. Grubel <pagrubel at tularosa.net> wrote:

> I'm new so if I am stepping out just let me know. Why couldn't you email
> them their password instead of resetting it, but only when they have lost
> it. I hate it when I have to go through resetting one and yes I'm one who
> usually doesn't go to the site. I am mostly a lurker because I keep
> "thinking" of re-entering the field. You would still eliminate the monthly
> mailing of the password.
> Pat
>
> -----Original Message-----
> From: systers-dev-bounces at systers.org
> [mailto:systers-dev-bounces at systers.org] On Behalf Of Robin Jeffries
> Sent: Thursday, May 28, 2009 8:56 PM
> To: Malveeka Tewari
> Cc: systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> Subject: Re: [Systers-dev] Considering LDAP and OpenID
>
> On Thu, May 28, 2009 at 12:07 PM, Malveeka Tewari <malveeka at gmail.com
> >wrote:
>
> > Hi Sarah
> >
> > I am the student who'll be working on this project - extending mailman
> > support for single sign on.
> > >From what I gather from the discussion, the issues,  with using mailman
> > passwords is that they are not not very well protected.
> > But if we can fix these issues with mailman for our implementation,
> openID
> > seems to be a good idea to work on.
>
>
> One thing to think about.  Because systers can go years without accessing
> the site, they often have to have their password mailed to them when they
> do
> want to access the site.  We could eliminate the monthly "here are your
> passwords in plain text", but we still need a way of providing passwords to
> users who have forgotten.  The obvious solution is to reset the person's
> password, send them a random generated password (plaintext), and then force
> them to reset it to something when they first log in.  That's a lot of
> extra
> steps.  Granted, we will get higher security that way, but it's not like we
> have had security breaches (everything on the site has been sent plaintext
> to 3000 women).  So where is the balance here between usability and
> security
> (Not sure I know the answer, but I want to provoke the discussion)
>
>
> >
> >
> > So I guess we can agree we want to implement openID provider for a *more
> > secure version* of mailman. Can we?
> > I'll start working on that. I'll go through the openID enabled mailman
> > support and figure put what places we need to strengthen the password
> > security.
> > (Or if we are coming with Systers wiki then we can use the Systers wiki
> to
> > act as the openID provider) I think we can start implementing an openID
> > provider module for the mailman first, test the effectiveness of single
> > sign
> > on and then once the wiki is up and working we can consider whether or
> want
> > we want to make the Systers wiki as the openID provider.
> >
> >
> > About Robins mail,
> > I might be a bit biased here but using openID should not be very
> difficult
> > for Systers users to adapt to. It is a new idea agreed, but using openID
> > would mean they would not need to remember separate usernames and
> passwords
> > for each of their Systers wiki or other systers affiliated accounts.
> > It appears that we want to extend openID support for only Systers
> > affiliated
> > accounts. In that case we would not need to worry about openID being used
> > for bank accounts. Also one can use openID for acessing bank accounts
> only
> > if banks allow use of openIDs.
>
>
> Right now 95% of systers have one password to one part of systers (that
> might be an underestimate).  Probably 10% of them will want to access or
> write to the wiki in the first year.  From their perspective, there is no
> issue of needing to remember separate usernames and passwords now --  so
> anything you do is more work for them.  It might be worth the extra work
> for
> the extra value, but we have to consider the value to our users and to us
> the administrators (where the negative value is having to handhold a lot of
> confused users through the process).  I'm especially concerned about it
> interfering with new users getting accustomed to the site.
>
> Robin
>
> >
> >
> > Looking forward to the summer of coding :)
> >
> > Thanks all
> > Malveeka
> >
> >
> > On Thu, May 28, 2009 at 7:07 PM, Sarah Mei <sarahmei at gmail.com> wrote:
> >
> > > On Wed, May 27, 2009 at 5:33 PM, Jennifer Redman <jenred at gmail.com>
> > wrote:
> > > >> Is the goal to allow single sign-on to several Systers-related
> sites,
> > > >> for Systers members, without making them register for each site?
> > > >
> > > > Yes, but using Mailman member information (uid and password) as the
> > > starting
> > > > point.
> > >
> > > Oh, ok - so the plan is to extract and encrypt the Mailman data,
> > > import it into an application that can be an OpenID provider, and use
> > > that as the basis for single sign-on?
> > >
> > > One caution, Mailman stores passwords in plaintext, and emails them to
> > > you once a month. Unless as part of this process they're encrypted
> > > (and the monthly emails turned off, and mailman patched to use
> > > OpenID[1]), it's not a great base for a single sign-on system.
> > >
> > > >> And/or, do you want to allow Systers to use the Systers OpenID
> > > >> provider for other services that take OpenID? I'm thinking of
> > > >> non-Systers-affiliated sites like Stack Overflow.
> > > >
> > > > This is a question we are working on answering.  What do you think?
> > >
> > > Given that we're talking about my Mailman password here, I don't think
> > > I'd use it. Plus, it's sort of a separate project - maybe for the
> > > summer, we can focus on getting some good infrastructure set up for
> > > single sign-on, then take it from there. It would make for a more
> > > achievable project. :)
> > >
> > > > OpenLDAP would be used primarily for authenticating against specific
> > > > applications for Systers running on Systers' infrastructure.   For
> > > example,
> > > > we set up Mediawiki for Systers to use and then use OpenLDAP as our
> > > > authentication tool.  (Could also be any of the major CMS's.)
> > >
> > > OpenID could work this way too. When you install an OpenID provider,
> > > you can restrict which sites it will authenticate - just blacklist
> > > all, whitelist the existing Systers sites, and edit as needed.
> > >
> > > BTW, setting up an OpenID provider is pretty lightweight. For
> > > instance, the OpenID extension for mediawiki allows you accept OpenID
> > > logins for mediawiki, and also allows user pages to be OpenID URLs
> > > (i.e., it can be a provider, too). The plugin for wordpress works
> > > similarly.
> > >
> > > > One of the questions is would Systers be interested in having a
> > "Systers"
> > > > OpenID that they could use to authenticate against other non-Systers
> > > sites,
> > > > and if so what are the implications of running an OpenID Identity
> > > Provider
> > > > (security and system overhead).
> > >
> > > I think we can put this off until OpenID is running internally
> > > (meaning not within ABI, but for Systers logging into other pieces of
> > > Systers infrastructure). Then we can evaluate the system
> > > administration and overhead costs and see if it's worthwhile to
> > > extend.
> > >
> > > > Do you know if there is way to restrict people accessing Systers
> > > > infrastructure with their non-Systers OpenID?  Maybe configuring the
> > > > application or framework to accept only Systers as the OpenID
> Identity
> > > > Provider?
> > >
> > > Yep, this is a basic config setting in both OpenID providers, and
> > > OpenID acceptors. Providers can blacklist/whitelist sites, usually by
> > > URL (the exact method varies depending on the provider). So a provider
> > > can say "I only authenticate for sites ending in systers.org."
> > > Acceptors can say "I only take Systers OpenID." In that way we have a
> > > closed system that won't accept outside OpenIDs, won't authenticate
> > > against external sites, but leaves us the option to open the latter if
> > > we want to, once we know the system administration and resource
> > > overhead of internal-only use.
> > >
> > > Sarah
> > >
> > > [1] Mailman with OpenID support:
> > > http://www.openidenabled.com/unsupported-software/
> > > You'd definitely want to audit this code and see how up-to-date it is.
> > >
> > >
> > > To unsubscribe from this conversation, send email to <
> > >
> systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticati
> o%2Bunsubscribe at systers.org <o%252Bunsubscribe at systers.org>>
> >
> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org>
> <systers-dev%252Bauthe
> nticatio%252Bunsubscribe at systers.org<nticatio%25252Bunsubscribe at systers.org>
> >
> > >>
> > > or visit <
> > > http://systers.org/mailman/options/systers-dev?override=9&preference=0
> >
> > > To contribute to this conversation, use your mailer's reply-all or
> > > reply-group command or send your message to
> > >
> systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> <systers-dev%2Bauthenticatio at systers.or
> g>
> >
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at systers.org>
> <systers-dev%252Bauthenticatio at syste
> rs.org>
> > >
> > > To start a new conversation, send email to
> <systers-dev+new at systers.org <systers-dev%2Bnew at systers.org><
> systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>>
> > <systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org> <
> systers-dev%252Bnew at systers.org <systers-dev%25252Bnew at systers.org>>>
> > > >
> > > To unsubscribe entirely from systers-dev, send email to <
> > > systers-dev-request at systers.org> with subject unsubscribe.
> > >
> >
> >
> > To unsubscribe from this conversation, send email to <
> >
> systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticati
> o%2Bunsubscribe at systers.org <o%252Bunsubscribe at systers.org>>>
> > or visit <
> > http://systers.org/mailman/options/systers-dev?override=9&preference=0>
> > To contribute to this conversation, use your mailer's reply-all or
> > reply-group command or send your message to
> >
> systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> <systers-dev%2Bauthenticatio at systers.or
> g>
> > To start a new conversation, send email to
> <systers-dev+new at systers.org <systers-dev%2Bnew at systers.org><
> systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>>
> > >
> > To unsubscribe entirely from systers-dev, send email to <
> > systers-dev-request at systers.org> with subject unsubscribe.
> >
>
>
> To unsubscribe from this conversation, send email to
> <systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>>
> or visit
> <http://systers.org/mailman/options/systers-dev?override=9&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to
> systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to
> <systers-dev-request at systers.org> with subject unsubscribe.
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.43/2139 - Release Date: 05/28/09
> 08:10:00
>
>
>
> To unsubscribe from this conversation, send email to <
> systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>>
> or visit <
> http://systers.org/mailman/options/systers-dev?override=9&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to
> systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to <
> systers-dev-request at systers.org> with subject unsubscribe.
>