From an Architecture stand point, What is a best approach Session[] or Encrypted Cookies?

Question

We are trying to decide the best decision to maintain state across our web application. We are incline to use Encrypted cookies on the browser, but some of our developers think we should go with Session variables on the server.

The main reasons why I think Cookies are a best approach is just because we will not depend on the app server in a load balance scenario.

The main reason against using cookies is the handling of the cookies could be messy.

What is your take on this topic?

EDIT 1:

Ok. I see from the first posts that neither approach is best. What will be the desire approach then?

Answer 1

There are two issues here. First is the difference between cookies and session. Unless you are using cookieless sessions (like unique IDs in the URL), session is just a cookie with a very short expiration. You can easily configure an application to share session across multiple servers by using a state server (ScaleOut, Velocity, SQL Server)

That of course assumes you are using the user's cookie to store just a unique ID, and linking that back to all the true data on the server, probably in a database. However:

Storing sensitive data in a user's cookie, even if encrypted, is not really that secure, because it has to be decryptable, which means it is vulnerable. Any time you choose to use two-way encryption in your application, you are taking on a much heavier cryptography burden to maintain the same level of security. If you don't have some considerable cryptographic expertise at your disposal, it's probably best to take the safe route and just not do it.

So in short, use built-in session or roll your own, either way make sure the only piece of information you send to the client is an unguessable ID that you tie back to the data stored on your end.

Remembering a user with a cookie:

Assign... a temporary ID associated with that user, like a GUID. Since GUIDs are astronomically unique and practically collision-proof, they're also virtually impossible to guess or predict from outside the system.

The advantage to rolling your own cookie-based session/"remember me" functionality is it gives you more control over how long the information is persisted, distributed, etc. On the other hand, it does represent more work, some of which is re-implementing functionality that comes out-of-the-box with ASP.NET Session. Typically I recommend using what's already there unless you can clearly articulate some driving business requirement that eliminates that as an option.