Forum OpenACS Q&A: Cookie Expiration Recommendations
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! :)
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
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 :)
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.
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.
incidently you should probably apply my patch (https://openacs.org/sdm/one-patch.tcl?patch_id=170) so that logout really does log you out. :)
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.
According to the Netscape cookie specs (see first post):
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 :)
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
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.
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.
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! ;)
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.