After a penetration test made upon an intranet application I'm developing, in ASP.NET MVC, one of the concerns raised was that the application supports concurrent user sessions and it is recommended that the application is reconfigured to support only one session at a time for any given user account.

Windows Authentication is being used. This means the user doesn't have to log in to the application, obviously. The application simply checks the Windows Identity IsAuthenticated property before proceeding with any action. The Session can't be timed out either. There is no configuration available, as far as I'm aware, that can limit the user to a single session id.

Is this recommendation correct? If so, can I limit the user to a single session id given I'm using Windows Authentication?

2 Answers 2


For standard applications I usually raise this as a "low" priority finding, mainly as if an attacker has compromised an account, it can be a useful restriction to have a user only able to maintain a single session and log out old sessions when a new one is started, that way the attacker gets kicked out the next time the user logs in.

In this scenario the attacker would need to be signed into the domain account of the user in order to have access to their session, so really the control should be placed at the domain level (e.g. stop users having multiple concurrent domain logins) if that's desirable/possible in the context of your organisation

So I'd say that the recommendation doesn't really apply to the application that you're developing, as the application doesn't really have control over that aspect of authentication.


There is no configuration available, as far as I'm aware, that can limit the user to a single session id.

No, you'd have to do it yourself. Not sure how your auth-and-session model is working at the moment, but in general the approach would be to keep a persistent lookup table of user IDs to their session ID, and moan when there's a mismatch.

Is this recommendation correct?

For some kinds of application, it is arguably of some benefit to limit user logins, but it's not generally accepted as a baseline requirement, or even necessarily best practice. Web frameworks don't do it by default and most don't even give you a direct option to do it.

Weigh it up: might it legitimately be useful for a user to log in using two browsers, or two devices, or to log in without having logged out from a recent previous session? Or is usage typically so linear that this will never happen and it's more likely to be evidence of an intrusion? For me personally, the extra user hassle typically outweighs the marginal security benefit, but it will depend on your usage model.

The good news is that this is a classic pentest filler-finding and if you're down to worrying about concurrent sessions you are probably doing OK otherwise. :-)

  • It was the last outstanding item on the list of 10 items the pen tester found so yes, I thought I was doing okay!
    – Boggin
    Commented Dec 15, 2013 at 20:38

You must log in to answer this question.

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