Sessions As Password Equivalents
If you use sessions to track logins the session key acts as a password equivalent while the session is active. So if anyone can intercept that session key they can masquerade as the logged in user without knowing their actual password. Hence, sessions time out to improve security by giving only a small window that the session key can be used in. This of course drives users crazy because they have to login again and again.
It occurs to me though, that if you're using SSL and using cookies for the session key - it should be just as secure as basic authentication over SSL. The big exception is shared computers if the cookie lasts longer than a browser session. To handle shared computers you'd have a log out option and by default set the cookie to last only the length of the browser session.
Am I missing something or is it reasonable to have sessions that don't time out if you know that the connection is over SSL and it's not a shared computer? To avoid creating a session leak effect you may still want to time out sessions if they're unused for a week or a month or something and obviously memory management comes in but that should be fairly manageable.
Is this done? Is it reasonable? What kind of security risks does it create? There's certainly a lot of benefit to users…
August 20th, 2007 at 11:59 am
The security risk you increase is that of the unattended PC.
I find that most users are primarily bothered by sessions that time out while they’re doing something: sessions that time out a fixed time after being created, regardless of user activity; and sessions that time out after they’ve spent some time preparing a form for submission, discarding their work. You can solve the first problem by extending the life of a session each time the user makes a request. Ideally, you should also issue a new cookie value after each request (storing the last two values, in case there is a connection issue preventing the browser from picking up the new one) thus limiting the lifetime of a session key to the user’s next request (or log out, or time out, whichever happens first).
The second problem is harder to solve without introducing more security risks. Generally it just means you need your re-authenticate mechanism to exactly preserve and repeat any request, including a POST. If your application’s architecture doesn’t allow for that already, you’re likely in for a rough time.
August 20th, 2007 at 12:06 pm
No, users get annoyed whenever you interrupt their work flow - requiring them to log in again is such an interruption. As for unattended PCs, that’s a security risk that exists for all forms of standard HTTP authentication (basic, digest, NTLM etc) because the browser remembers the login details until the end of the session with no timeout.
August 20th, 2007 at 1:32 pm
Cross-site scripting vulnerabilities are incredibly common, and can be used to steal session cookies.
August 20th, 2007 at 3:44 pm
Re: cookies that just time out when the browser closes, the Java Servlet Specification says that the JSESSIONID one used
for Servlets expires when the browser closes. This is what
happens for cookies without explicit date:
The problem with generous expiration time in the server side is that memory is needed in the server for each outstanding request. This means for each robot that touched our page and, unless we are careful to specify a handshake to start a session, our memory will fly away.
August 20th, 2007 at 4:11 pm
Matt, XSS is probably going to be a major issue for you using any form of authentication because the session will be valid and timeouts won’t help because you can just keep sending requests to keep the session alive. You could even go so far as sending AJAX requests to change the user’s password in most systems.
Santiago,
There’s no need to use memory for your sessions and there’s no need to use the built-in servlet sessions either. You could replace the word session above with login token. You’d simply have an in-memory cache of recently used sessions and a database or filesystem store of the entire set of sessions - the number of sessions is then unlikely to become the bottleneck for scalability.