Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In the past, I've always used a single session per user setup, but I'm working on a project now where a user can be signed in from multiple locations/browsers at the same time.

What are the security concerns for single vs multiple concurrent sessions per account? Is one method considered best practice over the other? What other considerations should be made and how should the ideal solution be implemented?

share|improve this question
add comment

5 Answers

I personally do not see any security issue in the fact that the user can be signed in from multiple locations at the same time.

However, when this happens, it could indicate that the account is compromised, and used by another user at the same time. I think that the best solution would be to inform the user of the situation ("Hey, you are already logged in at another location"), and give him the choice to dismiss the warning, or to take action (typically change his password).

Obviously, it would be necessary to use stronger authentication before taking any action on the account.

share|improve this answer
1  
I think google mail is a good example. They will let you know when was the last account activity and you can even see a list of access type (browser/imap/mobile), location (country + ip) and when it happened. They also have an option to sign-out all other sessions. –  Yoav Aner Mar 25 '12 at 20:36
add comment

To add to the other answers, there's one other concern around allowing multiple sign-ons from a single account which is that it can enable users to shares logins to the system, which in turn could affect any audit trails that the application stores.

My feeling in terms of implementing this would be that the best way to handle it would be that when a user who is already logged in tries to authenticate, you notify them that they're already logged in and ask them if they want to sign out of the other system and sign in at their current location. If they do, terminate the existing session.

share|improve this answer
2  
As everything, this is application-dependent. I'd hate it if Stack Exchange did this. –  Gilles Mar 23 '12 at 21:05
    
Yes, I see this as encouraging bad behaviour (sharing logons). –  Andrew Russell Mar 25 '12 at 7:44
add comment

If the account has been compromised, the attacker is statistically unlikely to use it at the same time as the legitimate user. Detecting accounts used from multiple locations and reacting to suspicious patterns can be useful (keeping in mind that you need to manage the user experience on false positives), but specifically detecting simultaneous logins doesn't help.

Multiple logins from one location could be the user wanting to use a different browser (how likely that is heavily depends on how technical your users are). On the other hand, it could be someone actively sniffing on a wifi connection. This is especially relevant if your application's design makes it easier for a sniffer to grab the user's cookie than to grab his authentication data — but arguably if that's the case you're doing something else wrong, such as not using HTTPS for everything you should. Note furthermore that if the attacker is using the same browser behind the same NAT, you may not be able to reliably tell the attacker from the legitimate user.

Switching to a different location could be the user switching from one device to another (leaving home and switching to my cell). It could even be a mobile device changing IP providers (getting out of range of the campus's free wifi and switching to my 3G connection).

For most applications, allow concurrent logins and treat connections from unusual locations (not necessarily simultaneous) as suspicious. A notification (not scary (“you've been hacked”) or disruptive (a banner, not a modal popup), just informative) of prior and concurrent locations can alert the user; be sure to provide a way for the user to find out what he should do if he thinks something untowards is going on. A few applications such as banking should use stricter rules, but that isn't the norm.

share|improve this answer
2  
one case where a compromised account is likely to be logged in at the same time as the user would be in a web enabled application where an attacker has managed to compromise a session token but not the users password. In that case the attacker has to keep the session live to maintain access and limiting users to a single valid session can be useful. –  Rоry McCune Mar 23 '12 at 20:51
    
@RoryMcCune Indeed, that's what I was thinking of, but I was unduly eliptic. Thanks. –  Gilles Mar 23 '12 at 21:05
    
Hey @RoryMcCune, the system would probably know about only one session in the case of session hijacking (unless ip checking and/or browser fingerprinting is also used). So this is not the same as allowing multiple sessions for the same user. –  Andrew Russell May 24 '13 at 4:14
add comment

While I agree with the other answers here in the general case, there are some regulations (e.g. PCI-DSS) that require you to prevent this.

So if you fall under any of those, you dont really have much choice in the matter.

share|improve this answer
    
I can't see it in PCI-DSS v2 @Avid –  Andrew Russell May 24 '13 at 4:36
add comment

One more thing I'd suggest to consider is the consistensy of information in the application, in addition to mentioned points of possible login sharing and compromise of accounts.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.