[Systers-dev] Fwd: cookies and sessions

[Robin Jeffries]

One thing to point out, in our quest for a balance between usability and
security, is that the typical syster logs into mailman less than once a
year.  For the wiki it would be more often, though if we keep the content of
the wiki as public content, then there would be a small number of writers
who log in regularly and others who never log in.  I'm not sure what to
predict for other applications, but I don't see people checking on anything
we offer on systers with the frequency they check their email or facebook
accounts.
So having a cookie that expires after a month will be, for most systers, the
equivalent of having a cookie that expires at the end of the session.

Based on the various discussions here, I'm coming to the conclusion that an
openid signon, where systers is the provider for all systers apps, but no
others, will give us the best security, the least amount of implementation
hassle, and the best usability we can get short of no-siginon.  Has anyone
come to a different conclusion or want to offer a counter argument?

Robin

On Fri, Jul 3, 2009 at 2:24 PM, Sarah Mei <sarahmei at gmail.com> wrote:

> Sorry for the late reply - I'm catching up on email.
>
> > On Mon, Jun 15, 2009 at 3:15 AM, Robin Jeffries <robin at jeffries.org>
> wrote:
> >>     - I'm not sure which is more doable for the set of applications we
> want
> >> to yoke to the systers login -- adding the step of checking for a cookie
> or
> >> adding openid/openldap.
>
> In general, adding Mailman-cookie-handling would require more custom
> code than OpenID-based login. Most modern webapps have a module
> available for OpenID, but there aren't generally modules for
> interpreting Mailman cookies.
>
> On Sun, Jun 14, 2009 at 11:50 PM, Malveeka Tewari<malveeka at gmail.com>
> wrote:
> > Even OpenID would need us to change applications. To enable single sign
> on
> > with OpenID we would need to  implement OpenID relying party in the
> > application.
>
> In most apps, you'll just need to install the OpenID module and
> configure it appropriately to only accept Systers OpenID. That may
> require some minor code changes.
>
> >    - how do we communicate to systers how this works?  It's going to be
> >> very strange that you have to log in to applications sometimes and not
> other
> >> times.  And people will never associate clearing their cookies with
> this.
> >>  So we need to think about a "UI" to this that communicates both what's
> >> happening and the risk without being in your face.
> >
> > I agree, this is a concern with OpenID as well. I hope the seniors will
> have
> > some suggestion on this.
>
> I think we're actually dealing with two separate issues here:
>
> 1. For each app, when a user visits, how does the app determine
> whether or not they're logged in?
>
> If we're using OpenID, Systers will use their OpenID credentials to
> log in to each application the first time they visit it. That is,
> single sign-on in this case does NOT mean that if they're logged in to
> one app, they're logged into all the others as well. However, they'll
> be able to use the same set of credentials with each app.
>
> Note that under this scenario, each application will set its own
> cookie once the Syster is successfully authenticated. So even with
> OpenID, we're still setting and reading cookies - but the
> cookie-reading code is part of the app, and we wouldn't have to modify
> it to recognize Mailman cookies.
>
> 2. Once a user is logged in to an app, how long can they stay logged
> in before it expires?
>
> This is generally an application setting. In the wild, timeouts range
> from a few minutes to never. If you say never, then whoever's on that
> computer can forever access that application. I suggest setting a
> relatively long timeout - say one month. Whatever you decide, it
> should be consistent across the apps.
>
> >> 1.  What are the situations where someone else being able to log on as
> you
> >> causes problems?  They could unsubscribe you from systers, they could
> put
> >> things in the wiki under your name that are embarrassing, they could
> upload
> >> inappropriate pictures of you.  On the other hand, this would also allow
> >> systers to do this (e.g., slander someone else on the list) and have
> >> plausible deniability.) Is the risk high enough to rule out this
> solution.
> >>  My feeling is that if someone has a housemate/boyfriend/partner who is
> out
> >> to get them, there are so many ways to do it, and this is rare enough
> that I
> >> wouldn't do much to guard against that.  After all, we can fix up the
> "bad
> >> stuff", unsubscribe the person (interesting question, is there a check
> that
> >> such a person is a member in the code?  Could there be?) and tell the
> syster
> >> who was embarrassed that they needed not to be so sharing with
> untrustworthy
> >> people.
>
> There are other scenarios - someone's laptop is stolen, someone sells
> their computer without cleaning it out, someone logs in on their work
> computer and then gets laid off and can't go back to their desk before
> leaving...there are many situations in which, if we have eternal
> cookies, unauthorized people could read Systers list email and/or
> access other applications. I think requiring users to enter their
> credentials once a month is a useful compromise.
>
> >> interesting question, is there a check that
> >> such a person is a member in the code?  Could there be?
>
> Well, if we're doing OpenID, presumably everyone in the database was
> exported from Mailman. We could modify the OpenID acceptance code to
> also make sure they are actually subscribed.
>
> > 2.  Any of your security experts aware of ways that cookies that allow
> one a
> >> "free" login to a wikistyle app or to mailman could create deeper
> security
> >> holes?  e.g., the ability to invade our server?
>
> It's certainly happened before, due to security holes in the apps. As
> long as Mailman and the other applications are kept up-to-date, you're
> probably ok.
>
> >> BTW, for the forseeable future (till ABI becomes rich :-), I would
> expect
> >> all our applications to be on a single server.
>
> I certainly hope ABI becomes rich! :) If everything's going to be a
> single machine, the apache config is slightly more complex, and we'll
> need to keep an eye on memory usage...otherwise not a big deal.
>
> Sarah
>
>
> 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.
>