26

We have a web app (Django) that logs users out if they haven't made a request within 1 hour.

From a security point of view, is it good practice to also block concurrent log ins? In other words, if a user logs in on his PC and then logs in from their mobile device, should they get logged out of the session on their PC?

  • 6
    This a matter more of functionality. Is this useful or not ? From a security perspective, why not set a logout timer ? – Overmind Feb 27 at 13:40
  • 9
    @binarym If User X gave away their credentials what stops them from leaving the account to the other person? Limiting to 1 session would help very very little and can be very inconvenient in many situations. If you threat model includes users giving a way their credentials then you can never assume that when user X logs in then they are really logged in... you would need to require the user to continously provide their fingerprint/retina scan etc to ensure they are sitting in front of the client themselves... – Giacomo Alzetta Feb 28 at 8:28
  • 3
    It won't stop them, but will make use of the service more painfull and probably discourage them sharing account.... – binarym Feb 28 at 8:48
  • 5
    As for your logout timer, would it be acceptable to time each session individually? As for whether there's a security risk, it depends. Stack Exchange allows concurrent logins. Does this produce a security risk for them? Think about how existing services tackle this problem, it looks like you're fixing the wrong problem. – Mast Feb 28 at 10:52
  • 2
    Well I'm permanently logged into my mail account from 3 different devices (simultaneously). Guess how I'd be puking fire and brimstone towards the service provider if that didn't work... – Damon Feb 28 at 19:12
58

There's no "one answer fits all" here. If it's simply a social media app, it might be sufficient to allow concurrent sessions, but also offer a way to terminate one or all sessions if the account is compromised. For many types of games, concurrent access means cheating, so should probably be disallowed, or at least designed in a way that the account can't cheat (e.g. there may be multiple latent sessions, but only one active session). For systems with sensitive information, like HIPAA- or GDPR-related information, 2FA should probably be required, short session times, and concurrent logins should probably be disallowed.

The important thing here is common sense. You need to ask yourself "what's the worst that could happen if concurrent access were allowed?" and "what would the user gain from having such a feature?" If the cons outweigh the pros, don't do it. If there's too much risk involved, don't do it. If it would convenience the user, consider allowing concurrent logins, perhaps with some caveats, such as only having one active session at a time, or allowing session management to disable sessions, and in any case, 2FA should probably be available, if not required.

  • 38
    Good answer. And one should also ask "what's the worst that could happen if concurrent access were not allowed?" – mentallurg Feb 27 at 19:20
  • 6
    @mentallurg Also a good point--users don't like being restricted any more than hackers do, so they might find try to ways to compromise security if it conveniences them. – phyrfox Feb 27 at 19:55
  • 13
    Where's the risk in having concurrent logins while also handling sensitive data? – David Feb 28 at 1:38
  • 4
    I don't see where the big risk is. Unless it's something where there's no good reason for the user to be logged into two devices (say for something like a cash register), it should be allowed, especially if the application works on both computers and mobile devices. – Kat Feb 28 at 7:41
  • If you want to maximise user engagement remove as many barriers as possible -- like logging in. If this is an e-commerce site then I'd be as permissive as the agreement with my payment gateway allows. – stevieg Mar 1 at 6:23
12

Concurrent logins should absolutely be allowed. Here's two concrete examples that should illustrate why:

  1. Imagine if using iCloud/iMessage/Gmail/Google Drive on your computer caused your Apple or Google account to be logged out on your phone, and vice versa
  2. Imagine if syncing Dropbox on your laptop caused you to be logged out on your desktop

Side note: since screen lockers exist, you should get rid of your 1-hour timeout too. Again, imagine if Gmail had this.

  • 9
    Your answer is too broad and only based on usage of consumer solution. Principles couldn't be applied as-is to every webapp, just because it works that way for GAFA stuff ... – binarym Feb 27 at 15:05
  • 11
    To the people who don't like this answer: your objections are almost certainly valid. Just remember that however important you think user convenience is, it's even more important than that. And it's good to be reminded of that. – Jared Smith Feb 28 at 3:07
  • 2
    @emory I don't disagree, but how much of that responsibility falls on the software? – Jared Smith Feb 28 at 16:27
  • 3
    @JaredSmith perhaps a better example is deleting a github repository. User convenience is of paramount importance. When something is not convenient, it should be because of a conscious decision rather than negligence. – emory Feb 28 at 16:57
  • 4
    @emory you can even still think of it in terms of user convenience - it's very inconvenient to have accidentally deleted your github repository or accidentally launched a nuclear missile. You could compare (frequency of intentional action x effort for process) to (frequency of unintentional action x effort to reverse) to determine the best level of effort to require for the process. – Michelle Feb 28 at 18:21
6

Whether you want to allow or disallow concurrent logins will very much come down to the threat model of your application. Typically I'd say that for higher risk applications (e.g. online banking or anything else transactional) disallowing concurrent logins is likely to be warranted.

In terms of the security benefit, the main one is that disallowing concurrent logins can reduce the risk of a session hijacking attack being able to persist for a long time.

So for example, if an attacker is able to steal a session token, if you disallow concurrent logins it would be invalidated when the user logged back in.

Another possible benefit is if a user leaves themselves logged in on a shared PC, invalidating that session the next time they login reduces the risk of another user of that PC gaining access to their session.

The trade-off is that users don't like being asked to re-authenticate a lot, especially if that is a high-friction process.

  • 2
    e.g. online banking ironically, I'm logged into a bank's online banking three times concurrently while typing this. I don't think "higher risk applications" alone is a good qualifier for disallowing concurrent logins. You also need to understand typical use cases, what actual threat you're trying to stop, and what your other methods for stopping that threat are. For online banking, it might be typical to allow concurrent logins from terminals the customer has used before (i.e. their home PC and mobile phone) but not from unknown locations (i.e. a random IP address in a different country). – dwizum Feb 28 at 16:27
  • 1
    Thus the opening sentence of my answer :) Whether you want to allow or disallow concurrent logins will very much come down to the threat model of your application online banking was an example of one possible higher risk application. Obviously your bank have taken a different determination of their threat model, and may be using a wider range of mitigtions – Rory McCune Feb 28 at 18:38
3

It's unlikely that concurrent sessions would be any kind of threat. However, stopping them could be inconvenient and, from a security perspective, actually harmful.

For example: Assuming an attacker gained access to an account, the simplest solution would be to change the password of said account. But what if the user could not log in to change the password because the session was already active somewhere else? The user is now locked out completely and the hacker has unlimited access.

A system where the previous session would instead be logged out might be slightly better, but not by much. The attacker can always make a bot to log in every so often and cause a denial of service to the account holder. This would likely make the user believe that there is a bug in the system rather than that their account was hijacked and so, is less likely to reset their password or take other measures.

Instead, a system where sessions can be viewed by the logged in user would be much more effective as a suspicious session could be reported and closed and the user would then know to change their credentials.

Of course one-session-at-a-time systems are useful, but mostly to prevent cheating in games etc. Combined with expiring sessions, IP verification on sessions and allowing the user to view active sessions, concurrent sessions should be perfectly safe.

1

User security is governed by two systems:

  • Login credentials: Here, if someone steals the user's password, disallowing concurrent logins (new devices not accepted), will help. But a better idea is to have 2fa. If the user intentionally shares their password, then there is very little security benefit from allowing just on concurrent login (since the user can logout and let the other person login).

  • Session management: Here the biggest risk is that session tokens can be stolen. In this case, multiple devices will use the same session, so to your backend, that's still just one concurrent login. In order to protect against that, you should checkout a solution like SuperTokens.io.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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