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?

5 Answers 5


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.

  • 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
    Commented Mar 25, 2012 at 20:36
  • "or to take action (typically change his password)" If it's a case of having left yourself logged in to a shared computer (so the attacker can't change the password because they don't know the old one), then the option of expiring the old session is important. A password change of course should be sufficient to do that but needn't be necessary. Commented Apr 18, 2014 at 10:58

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.

  • 5
    As everything, this is application-dependent. I'd hate it if Stack Exchange did this. Commented Mar 23, 2012 at 21:05
  • Yes, I see this as encouraging bad behaviour (sharing logons). Commented Mar 25, 2012 at 7:44

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.

  • 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. Commented Mar 23, 2012 at 20:51
  • @RoryMcCune Indeed, that's what I was thinking of, but I was unduly eliptic. Thanks. Commented Mar 23, 2012 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. Commented May 24, 2013 at 4:14
  • Note that if the attacker can control the browser enough to capture session cookies, he or she can probably also control the browser enough to POST requests to the target service using the victim's browser for transmitting the data. It seems to be that warning the user about possibly using the service from two or more locations in a time that doesn't allow traveling in person. For example, using the service from an European IP and 2 hours later accessing it from China using the same user account should raise a notice. Using multiple devices from single geolocation point is normal today. Commented May 26, 2021 at 15:49

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .