Is there any good reason why the authentication cookie and the session state cookie are two separate cookies?

Question

Is there any good reason why ASP.NET\'s session state cookie and the Forms Authentication cookie are two separate cookies? What if I want to \"tie\" them to each other? Is it po

Answer 1

I'll start with a solution, then an explanation followed by a recommendation.

Create a custom authorization attribute:

Since your application defines Authorized as follows:

• Logged in
• Must have values in Session["UserID"] and Session["Password"]

you need to define your own AuthorizationAttribute

    public class AuthorizedWithSessionAttribute : AuthorizeAttribute
    {    
        protected override bool AuthorizeCore(HttpContextBase httpContext)
        {
            if(httpContext.Request.IsAuthenticated && 
                Session["UserID"] != null && Session["Password"] != null)
                return true;

            // sign them out so they can log back in with the Password
            if(httpContext.Request.IsAuthenticated)
                FormsAuthentication.SignOut(); 

            return false;
        }
    }

Replace all your [Authorize] attributes with [AuthorizedWithSession] and you shouldn't need to put session check code in your controllers.

I don't know enough about your application, but saving passwords in session (even worse in plain text) is not a secure thing to do.

In addition, as RPM1984 said, the session cookie and authentication cookie are separate.

Explanation:

Think of the session as a bucket of info (on the server side) with your name on it. ASP.NET can take and put stuff in that bucket. ASP.NET gives you a name, your session id, and puts it on the bucket so it can know which one is yours.

The authentication cookie tells ASP.NET that you're authenticated and stores your authentication name in it. The authentication name is usually set by the developer of the application and is usually a unique key (think primary key in a DB) to separate you from the other users.

Recommendation to be more secure:

Encrypt the passwords before your store them. This is not total security, but it beats storing passwords in plain text and of course, if someone were to get a hold of the encryption key, they can crack the passwords.

Answer 2

Session != Authentication

The session state cookie tracks the user's activity during a browser session.

The forms authentication cookie tracks the user's authenticated activity during a given time period, specified by the expiration date of the ticket and whether or not you have created a persistent cookie (e.g "Remember Me" checkbox).

You shouldn't be touching the session cookie itself, and all it contains is an identifier to tie the client session (browser) to the server.

If you need to access the session, use HttpContext.Current.Session.

What exactly are you trying to "tie" together?

What does SomeStaticClass.WasSessionStateLost do?

Answer 3

Rather than using session, which is short lived you could cache in the System.Web.Cache. With this you can add events that are called before an entry is removed and decide accordingly if the cache should be cleared. You can set a higher time-out value on that, with the added bonus that you're not storing the clear text password in a file or database anywhere. Another bonus is you won't be vulnerable to session hijacking.

Of course if the application pool recycles the cache is gone, and as it's in memory load balanced machines will be out of sync, but Velocity or another distributed, out of process cache system would solve that.

It's not perfect though, entries may be dumped due to pressure on the cache, and of course you know this is all a bad idea anyway, so I'll skip that lecture.