Forum OpenACS Q&A: Cookie Expiration Recommendations

Posted by Jason Khong on 03/26/02 09:04 PM

Hi everyone, I've got a private OpenACS 3.2.5 site running for only authorized users. Security is an important issue, but users seem to keep forgetting to log out after they're done :)

Here is what I'm considering:
1. Setting the ad_session_id cookie to timeout after a short time (to 2 hours or so), OR
2. Setting the ad_session_id cookie to timeout after they close the browser (by changing sec_generate_session_id_cookie to NOT specify a max-age, so that the cookie defaults to expire at end of browser session; see http://www.netscape.com/newsref/std/cookie_spec.html )

Which is the more secure of the two options?

At first glance, option 2 seems more secure to me. But it seems odd that this option is rarely mentioned (at least I didn't notice it in the docs) or that this isn't the default behavior in OpenACS. So I'm bringing this up in case there's some glaring issue that I've missed.
Share your thoughts! :)

2: Response to Cookie Expiration Recommendations (response to 1)

Posted by David Walker on 03/26/02 09:17 PM

Do both.

Option 1 limits the amount of time a hacker who somehow manages to steal a cookie has to break into your site as well as limiting the ability of someone to sit down at that person's desk and use your site.

Option 2 limits the ability of someone sitting down at that person's desk and start using their logged in session.

Accomplish option 1 with the following parameters from parameters/site.tcl
        ns_param SessionTimeout 7200
        ns_param SessionLifetime 10800

and option 2 with this parameter
        ns_param PersistentLoginDefaultP 0

3: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jason Khong on 03/26/02 09:42 PM

Hi David, thanks for your input.

Can you please explain to me what the "PersistentLoginDefaultP 0" actually does?

I just tried using those params you mentioned (its the same as what I did before the quick "no expiration date" hack for option 2). The problem is that if a user closes his browser without logging out, anyone sitting at his computer can still access his account within the 2 hours that the session cookie takes to expire.

I do agree however with your comments on option 1. If there's a way to make a cookie expire after x hours or when user closes browser, *whichever comes first*, then it'll be perfect!

The problem with applying only option 2 (my quick fix) is that a user might end up at some public internet terminal that does not allow the browser to be closed. Then if the user forgets to log out/rushes off to catch the plane without logging out then the cookie will remain active forever...

Anyway, if the params you mention can achieve both option 1 and 2 the way I hope for, then please correct me about my comments and tell me quick so that I can revert to that :)
Thanks.

4: Response to Cookie Expiration Recommendations (response to 1)

Posted by David Walker on 03/26/02 09:52 PM

I believe that PersistentLoginDefaultP prevents a persistent cookie from being set. The system may still recognize already set persistent cookies unless you either clear out the active sessions table or clear the cookies on the user's machine. The system itself will clear out the sessions table after SessionLifetime expires.

The problem is that if a user closes his browser without logging out, anyone sitting at his computer can still access his account within the 2 hours that the session cookie takes to expire.
If no persistent cookie was set then this should not be the case. Once the browser is closed the cookie is deleted and logging back in will require a password.

5: Response to Cookie Expiration Recommendations (response to 1)

Posted by Tom Jackson on 03/26/02 10:27 PM

You should use both methods and have a session timeout as short as users will put up with. Sessions timeout on a lack of activity, not since the initial cookie was set. If you are actively using a site a session can continue or renew without the user having to login again. Try something like 10 minutes (600sec) to 20 minutes.

6: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jonathan Ellis on 03/26/02 10:44 PM

PersistentLoginDefaultP doesn't prevent a persistent cookie. It just makes the "save my password" checkbox default to unchecked rather than checked.

incidently you should probably apply my patch (http://openacs.org/sdm/one-patch.tcl?patch_id=170) so that logout really does log you out. :)

7: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jonathan Ellis on 03/26/02 11:24 PM

another note...

SessionTimeout is actually "max time since last issue before session times out," so a session can time out if it is idle for only SectionTimeout - SessionCookieReIssue.

8: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jonathan Ellis on 03/26/02 11:51 PM

finally, the reason that it's ok that session_id expires after N seconds (rather than on browser close) is that sec_read_security_info requires both session_id and user_login cookies to be set. the later is only set if user says "save this info on my computer."

9: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jason Khong on 03/28/02 06:39 PM

More thoughts...

According to the Netscape cookie specs (see first post): <br?

  expires=DATE
    The expires attribute specifies a date string that defines the 
valid life time of that cookie. Once the expiration date has been 
reached, the cookie will no longer be stored or given out.
    ...
    expires is an optional attribute. If not specified, the cookie 
will expire when the user's session ends.

So it's not possible to set a short session timeout AND expire-on-close on the cookie at the same time (referring to ad_session_id).
So that rules out the easiest thing to do :)

10: Response to Cookie Expiration Recommendations (response to 1)

Posted by David Walker on 03/28/02 06:45 PM

2 cookies are used. The persistent cookie and the session cookie. The
session cookie is lost when you close your browser and on subsequent visits
the persistent cookie makes it possible to get a session cookie without
logging in.

So the reverse is true also. Remove the ability to set the persistent cookie
and a browser will lose the session cookie when closed and require a login to
re-enter the site.

11: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jason Khong on 03/28/02 06:59 PM

So I can think of only 2 options that will help me do what's most secure (session timeout after x seconds AND on browser close, whichever comes first).

Option 1.
Jonation, you mentioned that sec_read_security_info reads two cookies, "ad_session_id" and "ad_user_login". If one of them is set to timeout after x seconds, and the other to expire on browser close, then as a pair, they would fulfill my objective.
But I don't see the ad_user_login cookie being set my computer. I think its because by setting PersistentLoginDefaultP to 0 the login page didn't offer to save it.
If it's safe to enable PersistentLoginDefaultP and to set the ad_user_login & ad_session_id cookies to work in the above manner, then my problem is solved :) Jonathan, would appreciate if you could revert to me on this.

Option 2.
Just thought of this: since ad_validate_security_info reads the ad_session_id cookie to see if it's still valid ($last_hit + [sec_session_timeout] < [ns_time]), it actually works the same as setting a cookie to expire in x seconds.
Meaning something like instead of setting a cookie expiry date on the client-side, we let the server check if the cookie is still "fresh" :)
Then that leaves the client-side cookie's expiration date empty, thereby allowing it to expire at browser close.

If this theory is right, then it would also fulfill my objectives and I'll be one contented guy :)

So once again, share your thoughts!

P.s: My apologies for possibly over-extending this thread. Really hope to find a fool-proof way of shutting my users out. Such noble goals! ;)

12: Response to Cookie Expiration Recommendations (response to 1)

Posted by Jonathan Ellis on 03/28/02 08:39 PM

you're right; ad_user_login doesn't get set temporarily with -forever false; it doesn't get set at all. ad_session_id also contains user_id and that's apparently what gets used within a session. (Again, please note that PersistentLoginDefaultP just unchecks the "store login info" checkbox BY DEFAULT; users can still check this box themselves. it has NO EFFECT on what features are enabled/disabled. If you want to disallow this completely you'll have to hack the login scripts a bit.)

I'm not clear on how the user_id part of ad_session_id gets zeroed out after you close your browser and come back to the site but it does. Maybe someone else can clarify.