Comments on: Sessions As Password Equivalents http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/ Living in a state of accord. Wed, 03 Dec 2008 01:09:03 +0000 http://wordpress.org/?v=2.6.5 By: Adrian Sutton http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105400 Adrian Sutton Mon, 20 Aug 2007 06:11:15 +0000 https://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105400 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. 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.

]]> By: Santiago Gala http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105396 Santiago Gala Mon, 20 Aug 2007 05:44:10 +0000 https://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105396 Re: cookies that <em>just</em> 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 <a>cookies without explicit date</a>: <blockquote> The cookie setter can specify a deletion date, in which case the cookie will be removed on that date. If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser. </blockquote> The problem with generous expiration time in the server side is that memory is needed in the server <em>for each outstanding request</em>. 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. 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 cookie setter can specify a deletion date, in which case the cookie will be removed on that date. If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser.

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.

]]> By: Matt Brubeck http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105388 Matt Brubeck Mon, 20 Aug 2007 03:32:51 +0000 https://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105388 Cross-site scripting vulnerabilities are incredibly common, and can be used to steal session cookies. Cross-site scripting vulnerabilities are incredibly common, and can be used to steal session cookies.

]]> By: Adrian Sutton http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105382 Adrian Sutton Mon, 20 Aug 2007 02:06:46 +0000 https://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105382 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. 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.

]]> By: Byron Ellacott http://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105381 Byron Ellacott Mon, 20 Aug 2007 01:59:07 +0000 https://www.symphonious.net/2007/08/20/sessions-as-password-equivalents/#comment-105381 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. 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.

]]>