[Systers-dev] Fwd: cookies and sessions

[Sarah Mei]

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