1

After reading this and this, I am wondering if it is considered secure to use the default ASP.NET sessionID as a means to authenticate the user. I know it would be better to implement ASP.Identity, which has a much longer 'fedAuth' cookie next to the ASP session mechanism, however due to constraints, this is very difficult. Of course, in case the ASP sessionid is not secure enough to use as a means to authenticate the user, nothing is impossible.

What I want to know is, is it considered bad practice today to use the ASP.NET sessionID as a means to verify the user, when both the HTTP-only and Secure flags are set? A security comparison with ASP.Identity's cookie authentication would be nice, as the first source I listed seems to have a custom implementation, which I certainly do not want to implement. I'd rather see a comparison with something established.

Community
  • 1
Michael
  • 5,393
  • 2
  • 32
  • 57

2 Answers2

1

Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in).

Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ASP.NET identities uses a collection of values that describe the session identity encrypted against the machine key.

Sessions relies on an in-memory map (or persisted to DB) of the decrypted Session ID to session information, whereas Identities just rehydrates the session identity directly from the value stored in the cookie.

On the one hand, Sessions isn't portable because it relies on a pointer back to the value in memory so if you remove that pointer the session is dead. On the other hand, it really doesn't scale well.

From a purely security perspective they are more or less on par with each other, but Sessions was deprecated for a whole host of non-security-related reasons.

Steve
  • 15,155
  • 3
  • 37
  • 66
0

Adding ASP.NET Identity should not be that big of a job. Guide here.

Session has not been designed as an authorisation mechanism. It has some characteristics that make it unsuitable such as using the same identifier pre and post authentication, making it vulnerable to session fixation. Also, it is difficult to check authorisation status for page access, as each page will need to have its own manual checks implemented.

Having said that, some authorisation mechanisms in the old Forms Authentication were not perfect. For example the sign out method did not clear the server side logged in state:

Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.

I'm not sure if this is now fixed in the new ASP.NET Identity.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178