Wednesday, May 27, 2009

Simultaneous Sessions for a Single User

It's a common request or recommendation that a web application not allow a user to have more than one session active at a time. In other words, after a user logs into an application, he should not be permitted to open a different type of browser (or use another computer) to log in again until his first session has ended. I've recommended this myself, but it's always been kind of muddy as to why this should be done. It is not trivial to implement this feature in the code. Recently, one of our clients wanted to better understand the reasons behind this recommendation. I was given the task of explaining.

The bottom line is that I could not find one strong, clear-cut reason for disallowing simultaneous sessions for a single user. There are a number of scenarios where it might help. Listed below are the reasons I came up with for implementing this feature. Please let me know if you have other ideas on this subject.

  • An application has a licensing scheme that allows only a limited number of concurrent users or requires users to pay for access or premium content. A technical control to prevent simultaneous sessions for a single user ID would limit the financial harm caused by users sharing login credentials.
  • It is out of the ordinary for a user to be logged in from more than one location (or more than one type of browser) for a given point in time. Anything out of the ordinary should be assumed to be a potential security risk.
  • An attacker somehow steals a user's credentials (perhaps by sniffing unencrypted HTTP traffic) while the user was authenticating to the application. The attacker immediately tries to log in with the stolen credentials. The application sees that the user is already logged in and returns an error to the attacker, thus temporarily protecting the account.
  • An attacker shoulder surfs to obtain a valid username (but not the password). He then immediately proceeds to run a password guessing or dictionary attack hoping to determine the password. If his attack happens to be successful during the time the legitimate user is logged in, it would prevent the attacker from gaining access.
  • An attacker and a victim log in such that their sessions overlap. The application displays an error message that alerts the victim that someone else is using his account. The victim may contact the site owner, spurring an investigation, which might uncover a compromised account.
  • It could help ensure data integrity and non-repudiation. A user may have multiple authenticated sessions at the same time, and one of the sessions might be used to make a critical change. If a user claims he never made such a change, it could be a problem for the logs to show that two authenticated sessions existed and the user claims he was logged in only once.
  • It could help defend against a malicious user who wishes to overload the server memory by creating an excessive number of authenticated sessions. Authenticated sessions typically use much more memory on the server than unauthenticated sessions. With valid credentials and no limit to simultaneous sessions, a user could potentially create a denial-of-service condition.
After my research, I came to the conclusion that disallowing simultaneous sessions often does not increase an application's security posture enough to justify the required development and implementation cost. Obviously there are some special situations, like the licensing issue, where it could make sense.

This feature may actually introduce new problems. Let's say a user logs into an application and his machine crashes or the power goes out. A few minutes later, when trying to log in again, the user is denied access and told he's already logged in. Of course, it's true from the server's perspective (his session is still active), but now there's an angry user shouting profanities at his computer. Unless the user knows his previous session ID (fat chance), there's nothing for him to do but wait until the session expires due to inactivity or call your customer service department and complain.

13 comments:

jwilliams 5/28/2009 7:33 AM  

The biggest danger in my mind is from concurrency issues. User sessions are often considered threadsafe. So a user can set up a purchase (for example) for $500 in one session, and then stomp on it by updating the a $5 transaction in the other, and end up with the wrong price. These problems are widespread, impossible to scan for automatically, and difficult to track down even if you know it's there.

Dave Ferguson 5/28/2009 8:34 AM  

Good point Jeff. I hadn't thought of that. If the app was written poorly enough to have concurrency problems, I bet the developers would fail at writing code to enforce one session per user. Would be nice if more of the frameworks out there had that capability.

The Grumpy Hacker 5/28/2009 10:00 AM  
This comment has been removed by the author.
The Grumpy Hacker 5/28/2009 10:39 AM  

I believe this 'folk-requirement' has become the more well-known, dumbed-down version of the real requirement: that a user's session token should not be duplicable. As Jeff indicated there may be valid reasons for disallowing more than one simultaneous session (because the cost outweighs the benefit), but there is no security implication so clear and obvious as to only allow this condition by exception rather than rule. Duplicable (or reusable if you wish) session tokens, however, are another story.

Jim Manico 5/28/2009 3:07 PM  

It's VERY common for users of mainstream online services to be logged in for long periods of time from multiple devices. Look at gmail, it's not uncommon to be connected from your iPhone all day, while reading your mail from IMAP for a browser simultaneously. Google then offers a feature where you can see all active sessions and shut some down. ESAPI is on route to support this in the future. I think this is a good design compromise when tasked with the (very difficult) feature of supporting only one user session at a time.

Dave Ferguson 5/28/2009 3:40 PM  

Jim, I remember you had suggested that feature for ESAPI a while ago. Glad to hear it is going to happen.

w0lf 5/29/2009 12:37 AM  

Yes Jim. Gmail has implemented this feature and its really good. But what if an attacker has already compromised your account and logged in before you. And when you try to login, he can keep logging you out. And by the time you contact support center, he might have done a major damage.
Wat if we simply notify the logged in user and also the user trying to log in about duplicate sessions. Atleast this can alert the victim and he can change his login credentials before the attacker plans to do so..

Lavakumar,  5/29/2009 5:39 AM  

Simultaneous Sessions is always a bad idea. Consider this scenario, User A logs in to an application and fails to log out like most users do, this session is hijacked by an attacker.
Even though User A might be logging in and logging out multiple times after this, the first session would still be valid and by sending regular 'keepalives' to the server the attacker can literally keep the hijacked session active forever, that's almost as good as an account compromise.
And the worst part is that the user cannot do anything to invalidate the hijacked session, changing passwords doesnt help.
The ideal scenario would be to invalidate any old sessions of an account when a new one is created, so at any given time there is only one active session for an account, which is the most recently created one.
To address the licensing problem, where multiple 'legitimate' concurrent sessions are required there is an alternative.
When a new session is created for an account then all existing sessions of the same account should be prompted to enter their password, this would allow legitimate users to continue their concurrent sessions by entering the password, while any hijacked sessions cannot be kept alive unless the attacker knows the victim's password, in which case it would not be a session thing anymore.

The Grumpy Hacker 5/29/2009 8:54 AM  

Let's say hypothetically your first scenario is on an "Internet Cafe" computer (user fails to log out, attacker "hijacks" session by sitting down at user's computer; there are already some assumptions such as the user did not close the browser window which would have discarded memory-only tokens and/or the application is using persistent tokens). Whilst it seems at first we would desire no simultaneous sessions, so that the real user can log in again later even if the attacker is still logged in on that cafe PC...what if that session had not been assumed and the user needed to log in later--but no so much later that the session had timed out? Without simultaneous sessions we would have to invalidate that older session. But the catch is (contrary to your second 'ideal' scenario) that if one has the user's credentials, one can knock the legitimate user offline at any time. Then it becomes a game of who can log in and change the password the fastest--in which case the user would have to try either a 'forgot password' option or call for support if there is any.

I do like your final suggestion, but not just because of licensing considerations. If a user legitimately needs a 2nd (or 3rd...) session we could assume it is because the 1st session's state needs to be maintained whilst the user does something completely different in another session that can't be done in the 1st whilst maintaining that needed state. If the app detects that a new session has been created, it should "grey out" the older session(s) until the newer session(s) is/are logged out, or require a password to re-enter a "greyed out" session at which time it "greys out" the previously active one.

Declare.James 5/29/2009 9:52 AM  

I believe that this issue is really overlooked in the security community. Concurrent sessions may not seem like that large of a security risk, but unless there is a need for it, it should never be allowed.
Anything that the client is unaware of, could be considered a security risk.
There are too many security risks involved with sessions, that are only occurring due to convenience and along with Security Questions and Password Resets, I would consider this to be in that category.

Great Post.

Lavakumar,  6/01/2009 3:47 PM  

@The Grumpy Hacker
I get your point. But once the attacker knows the victim's password then its pretty much 'game over'.
The user is not going to be logged in forever, so a patient attacker would wait for the user to log out and then login with the credentials. He could easily automate this part with a simple script.
In this case it would be still worse because the user wouldnt even know that there is another person parallely using his account.

Anonymous,  1/14/2011 1:15 PM  

Sorry to bring this back to life, but I am also currently researching the need for this control. I would also argue that this is a technical control that also prevents the sharing of user ids. The control forces users to each have their own individual identifier and thus provide more valid audit/forensic information.

Tāṇḍava 7/02/2012 3:27 AM  

My feeling is that if you are using a security platform that does not have an in-built mechanism for limiting concurrent logins then the possible security breaches caused by adding one outweigh the benefits.

The OWASP guidelines recommend that if a login session exists the user should have the option of terminating that session. This means having some inter-session communication, making a hole in the Chinese Wall that the platform places between different user sessions. If this goes wrong then information leakage is possible.

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP