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?
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.
Concurrent logins should absolutely be allowed. Here's two concrete examples that should illustrate why:
Side note: since screen lockers exist, you should get rid of your 1-hour timeout too. Again, imagine if Gmail had this.
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.
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
Commented
Feb 28, 2020 at 18:38
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.
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.
