[Systers-dev] Fwd: cookies and sessions

[Malveeka Tewari]

On Mon, Jun 15, 2009 at 3:15 AM, Robin Jeffries <robin at jeffries.org> wrote:

> 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
>

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. However, this step would be mostly the same standard set of
steps for all applications. Whereas, in case of using cookies - one would
need to figure how for each application how the app differenciates between
logged in and logged out. We are working on the OpenID support for mailman
presently. I sent this mail only to have another fall back option in case
the OpenID enabled mailman doesn't work well.

    - 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.

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?
>

This indeed is one imp concern, if the cookies are not cleared other people
can access their accounts.The users would need to clear the cookies on their
own.
But I am not sure  I get your concern about people not being able to post to
systers. If the cookies are cleared people just need to login again creating
fresh cookies. And then they can post to systers or am I mssing anything
here?

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.
>>
>
>