Form Authentication and Session State

Form Authentication and Session State

Form Authentication with default configuration is next to impossible to create a forged forms authentication ticket. The problem with depending on session state as an indicator of a logon session is that unlike forms authentication, it is trivial to create a valid session identifier.
A session identifier is nothing more than a 120-bit random number encoded using letters and numbers (this works out to a 24-character cookie value due to the way session state encodes the random number), there is a chance that we can easily create a perfectly valid session identifier. Of course, if we send such an identifier to Asp.NET, there probably isn’t going to be any session data associated with it. (We have 2^120 possible combinations to guess if you were actually trying to grab someone else’s session).
The configuration options for session state, unlike forms authentication, don’t include options for setting a cookie domain or a cookie path.
Another flaw of using session state for tracking logon status is the inability to set the secure property of the session state cookie. Unlike forms authentication, the session state cookie always flows across the network regardless of the state of any SSL security on the connection. If we think about it, this makes sense for a feature like session state because many applications break If the data in session randomly became unavailable when a user surfer between secure and insecure pages.
The whole point of a logon session is that it requires authentication to obtain a session, and once established there is persistent association between an authenticated user and the actual session data. Please check the image for a security feature comparison of forms authentication and session state.

The best way to think about session data is to treat session state as if it were data stored in forms variables on a page. Session state acts as a server-side store for this type of information.
Protecting Session Cookies
As with forms authentication in ASP.NET 2.0, the session state feature explicitly sets the HttpOnly property on the cookie to true. Because applications store interesting information inside of session state, ASP.NET protects the session identifier from client-side cross-site scripting(XSS) attacks.
The likelihood of an attacker ever guessing a live session cookie is astronomically low (with 120 bits in the session identifier, that works out to an average of 2^60 guesses required.
HttpOnly property prevents cookie hijacking.
Why SessionID is not encrypted like forms authentication ticket ?
The default session state cookie is a cryptographically strong 120-bit random number, there didn’t seem to be much point in layering the overhead of encryption and signing on top of it. Furthermore, not only is the session identifier a strong random number, because the session state identifier is stored in a session based cookie, the session ID changes from browser session to browser session.
With session state the only time we can really someone else’s session state is while that user’s session is still active. There is no such thing as an offline brute force decryption attack or hash collision attack with session state. With session state, an attacker must successfully guess (incredibly unlikely) or hijack (possible but difficult to accomplish) a session identifier while that session is still active somewhere in an application. Although an attacker could theoretically stumble across a session identifier associated with an expired session, this isn’t of any use because an expired session means that the data associated with that session is no longer available.
When you abandon a session, the session ID cookie is not removed from the browser of the user. Therefore, as soon as the session has been abandoned, any new requests to the same application will use the same session ID but will have a new session state instance. At the same time, if the user opens another application within the same DNS domain, the user will not lose their session state after the Abandon method is called from one application.
Sometimes, you may not want to reuse the session ID. If you do and if you understand the ramifications of not reusing the session ID, use the following code example to abandon a session and to clear the session ID cookie:
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
This code example clears the session state from the server and sets the session state cookie to null. The null value effectively clears the cookie from the browser.

Reference: Asp.Net security book related to roles, authentication by Stephan Schakow. Its a great book.