4

We are building a 3-tier web application with ASP.NET MVC in the middle. We are using a combination of straight MVC and WebAPI for responsiveness. The back-end data is secured using a token-based service.

Our intent is to request a new token for each user loging into the system. While all the tokens will be generated using the same user/password combination, we figured it would give at least some tracebility if we can associate a token to a username and session.

We are storing the generated token into the session state for simplicity and flexibility. We would need to require session state, even for WebAPI calls so we can access that token for WebAPI calls. We are requiring authentication before access our REST Resources.

I have read many posts on SO that make it sound like this is a bad approach. What are the alternatives? and what would be real limitations of this solution?

Thanks in advance for input

Eric Liprandi
  • 5,324
  • 2
  • 49
  • 68

2 Answers2

2

Session is relatively easily compromised. There is no encryption (though you can specify that it's a secure cookie, which helps) of the session cookie, or verification that it's valid. This makes it relatively easy to steal and/or attack.

In addition, session is not ideal for many other reasons, for instance whenever the asp.net worker process is recycled, the session will be lost. This will force the user to re-log in. So the session can be lost randomly, at any time because you cannot control when the worker process recycles (it can do so under a variety of reasons).

I really don't know the details of your token system, so it's hard to suggest alternatives, but you can look at the way FormsAuthentication generates auth cookies as a basis. You could also use FormsAuthentication and store your token in the userdata of the ticket.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • 1
    Session state can be stored in databases and the setup is fairly easy. http://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx – Ray Cheng Feb 23 '13 at 07:04
  • @RayCheng - What does that have to do with compromising the session cookie? – Erik Funkenbusch Feb 23 '13 at 07:51
  • @MystereMan if we use authorization and other session state management options (like State Server or SQL Server), would that address your 2 main points (security and process recycling)? – Eric Liprandi Feb 23 '13 at 16:19
2

You have to think if a system can be compromised due to the separation of Authentication and Session as ASP.Net stores the Session Identifier as a separate cookie to the Authentication cookie.

Take this overly simplistic example:

You want to force a user to change his password, no exceptions, on a person's first login, so in the code you set Session["MustCheck"] = true on Login.

The user is clever and realises this is controlled by the session. How do they get around it?

They delete the session cookie, thereby removing the current session and still being logged in.

There is now no "MustCheck" and so the user can completely avoid it

If you want to do something that covers all bases, cookies are the way to go.

You can use something along the lines encypting the value of the cookie where you encrypt the value using A PROVEN METHOD (do not use your own!).

the validated user ID or something immutable (ID) that is related to the user as a key.

You could also use one of the

Community
  • 1
  • 1
Dan
  • 12,808
  • 7
  • 45
  • 54