[Systers-dev] Fwd: cookies and sessions

[Robin Jeffries]

This is an interesting approach that perhaps we should discuss more.  We
already use cookies (so if I hunt I should be able to find you some code to
base this on) to allow people to unsubscribe from conversations -- as the
need to remember your systers password (which people rarely use) when
unsubscribing is a big barrier to use.  You have to authenticate the first
time on any computer, and then it keeps a cookie to say that this computer
is used by user A, so if user A tries to unsubscribe from another
conversation, it bypasses authentication.
Some general issues that occur to me:
    - 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.  Do we have a list of the applications we are
considering yoking (mediawiki, what else?)  It might be worth coming up with
a list of 4-5 categories of applications, and determine whether there is a
candidate opensource version and which approach would be more doable.  I was
assuming that adding openid could be done without modifying the app, but the
custom cookie solution will clearly require us to change each app
    - 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.

To think about use cases, some questions I'd like others to react to.

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.

The more difficult case is a syster who uses a public machine and leaves her
cookie there.  I think this is an issue in countries where the use of
internet cafes is common.  I'm not sure how likely/how serious this is (one
would assume the owners of these cafes clear out the cookies every day, but
that's probably naive of me).  This won't enable people to post to systers,
since we use email for that (they would have to have the syster's email
password), but could result in things we don't want on the wiki.  Are we
willing to take that risk?

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?


BTW, for the forseeable future (till ABI becomes rich :-), I would expect
all our applications to be on a single server.

Robin



On Sat, Jun 13, 2009 at 7:10 AM, Malveeka Tewari <malveeka at gmail.com> wrote:

> This is a more detailed mail about the use of cookies and sessions for
> enabling Single Sign On. I am planning to continue with mailman presently
> but I think we should keep this approach too at the back of our minds.
>
> Thanks
> Malveeka
>
> ---------- Forwarded message ----------
> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Date: Tue, Jun 9, 2009 at 5:46 PM
> Subject: Re: cookies and sessions
> To: Malveeka Tewari <malveeka at gmail.com>
>
>
> How would the administrator enable the cookie for users accounts?
> > I mean how do I save the cookies from session of one application and use
> it
> > for the other?
> >
>
> Cookies are not application-specific. Cookies are text files sent by the
> server to the user's browser, with a specified domain. All further requests
> by the browser to that domain should be accompanied by the cookie values.
> This enables an inherently stateless mode (browser sending intermittent
> requests to server, receiving responses) to act as a stateful mode by
> remembering data about the user between visits.
>
> If you try to set the user's session ID in one application, while already
> having it set from another application, and that value has the same
> variable
> name, will it be overwritten, causing the user to lose their session with
> the first application? Good session managers will read the user's cookie
> and
> use that (previously set) ID.
>
> If all your applications are on the same server, using the same cookies
> should be straightforward: the server will keep all its session data in the
> same place. If you are hosting applications on different servers, you may
> want to use one of the database session managers, host that on one of the
> servers, and teach all your applications to contact it across the network
> when needing sessions.
>
> What you need to do is look inside each application and find out "HOW does
> this tell the difference between a user that has already logged in and a
> user that has not yet logged in?". Once you know this, it will be simple to
> change that code to "if the session data includes 'authenticated=TRUE'",
> and
> in each of those applications, change the code for "do whatever we would
> normally do to mark the user as logged in" to "set 'authenticated' to
> TRUE".
>
> When this is done, each of your applications will make a single change to
> your server's stored session data, and each of them will look for that
> single change to determine whether the user is logged in.
>
> Just remember basic security: the content of cookies issued to the USER
> must
> have only the session ID, *not* their username and login status, because it
> is trivial to discover the content of cookies (remember, these are just
> *plain text files* stored by the user's browser), and attackers could
> easily
> edit their cookies to present a chosen username and appropriate "Hey, look
> at me, I'm logged in!" status, tricking your server into accepting that
> claim. Keep track of all that data on YOUR end.
>
> -Shade
>
>
> 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.
>