Web authentication state - Session vs Cookie?

Question

What's the best way to authenticate and track user authentication state from page to page? Some say session state, some say cookies?

Could I just use a session variable that has the ID of the user and upon authentication, instatiate a custom User class that has the User's information. Then, on every page, verify the session variable is still active and access basic user data from the User object?

Any thoughts? Any good examples?

Solution 1

There's no perfect way to do it. If you store it in a cookie you'll take flak that cookies can be stolen. If you store it in the session you'll take flak because sessions can be hijacked.

Personally, I tend to think a session is a little more reliable because the only thing stored on the client is a session key. The actual data remains on the server. It plays the cards a little closer to the chest, if you will. However, that's just my preference, and a good hacker would be able to get past shoddy security regardless.

No matter what you do, don't try to implement this yourself. You'll get it wrong. Use the authentication system provided by your specific platform. You also need to make sure you have adequate security precautions protecting the authentication token.

Solution 2

The problem with favoring sessions over cookies for 'security' is that sessions USE cookies to identify the user, so any issue with cookies is present with sessions.

One thing to keep in mind with the use of Sessions is data locality. If you plan to scale to more than one webserver at any point, you need to be very careful storing large amounts of data in the session objects.

Since you are using .NET, you will basically have to write your own session store provider to handle this, as InProc won't scale past 1 server, the DB provider is just a bad idea entirely (The whole point is to AVOID DB reads here while scaling, not add more), and the StateServer has a lot of capacity issues. (In the past, I have used a memcached session store provider with some success to combat this issue).

I would google for signed cookies and look into using that instead of either regular cookies or sessions. It solves a lot of the security concerns, and removes the locality issues with sessions. Keep in mind they come back and forth on every request, so store data sparingly.

Solution 3

I dont know if its THE BEST way to do it, but we are comfortable with the way we do it.

we have a custom user object that we instantiate when the user authenticates, we then use Session to maintain this object across the application.

In some application we combine it with the use of cookies to extend the session continuously.

Comments

[Chris Van Opstal]

Have you looked at using the built-in aspnet forms authentication? It uses cookies but is fairly robust in terms of security and would alleviate a lot of work.

[Bhaskar Neti]

It's nice but I need to verify a few other things about the user from a database. Can it do that?

[Shawn]

yes, you can store anything in the user's profile data. if you are unsure of how to create your own user system, i would only do it if the security implications are low

[lubos hasko]

that's kind of wrong, because cookies can be hijacked and session can be stolen (as its often implemented as abstraction over plain cookies)

[Eduardo Scoz]

You can have cookieless sessions in any platform. .NET offers it our of the box too.

[Greg Bacchus]

How is AppFabric distributed cache for session storage?

[Jeremy Pope]

This doesn't make sense, because you hijack a session by stealing a cookie. So its the same issue no matter what.

[msgmash.com]

@esteban Cookieless sessions put the session ID in the URL. I leave it up to your imagination as to whether this is more/less/just as insecure as using cookie.

[Admin]

I am just reading somewhere that you can use the combination of both.

[ColacX]

no man you cant steal a session or its data since its stored on the server. you can hijack it.

[TheMah]

Not exactly, sessions use cookies as a reference to them