For session management - that's not the only way to handle user information. Often the web server will store a unique hash value and temporarily store the users information on the server with the associated hash. Note: if you're not using sticky sessions on server connects or a distributed server side session object that users info will be lost on reconnect if they hit a different web head.

And no, it is not entirely good enough for session management, which is why when you're on amazon.com or other online sites and you go to your account you are prompted to reenter your password. It is another level of security, but nothing is perfect.

Amazon/ebay/etc would usually do this because they have unencrypted parts of their site you can be directed towards, or unencrypted services, which would expose the cookies in transmission for session information [although I'm pretty sure they've got secure cookies for some parts of their acct mgmt]. Online payment processing force https for cookies and for session management and sets server & client side session timeouts, expire the cookie to prevent any possible future session hijacking, as well as many other procedures to secure their online services. There's a lot to PCI compliance.

edit: as phil said, HMAC is good policy if you store information on users on the client side, but I wouldn't put anything more than user tracking or analytics info in there.

No, that's not how session tracking works. The server uses a cookie to assign you a temporary ID, and then creates a corresponding storage area "server side" which can contain data like credit card numbers.

> Rails 2 introduced a new default session storage, CookieStore. CookieStore saves the session hash directly in a cookie on the client-side. The server retrieves the session hash from the cookie and eliminates the need for a session id. That will greatly increase the speed of the application, but it is a controversial storage option and you have to think about the security implications of it:

If you're using cookie sessions, you should know better than to store sensitive information in the session.

This approach seems strange to me. Why is this approach taken? Why not encrypt everything?

I only really know anything about writing server-side web code from using Play Framework, which provides a "session" object for storing information in the browser using the cookies mechanism. Everything in the session object is kept encrypted on the client in a cookie.

The most common use for the session information is to store a user ID and/or a session ID, but I believe it not uncommon to use this to store additional small bits of information if this will take some load off of your database and/or cache, and to help the server be more RESTful/stateless.

Edit: It turns out that I was not quite correct about Play. Like Rails, it seems to only sign the session cookie, rather than encrypting it. From looking at some benchmarks for the performance of HMAC vs Blowfish, it seems that signing with HMAC can be up to 4X faster than encrypting with Blowfish.

We at Phusion have created an encrypted session store in the past (http://blog.phusion.nl/2010/04/13/announcing-encryptedcookie...). However we've found it to be of limited use (and indeed, it doesn't look like many people use it). If your data is sensitive then you're better off storing it on the server. If your data is not sensitive then encrypting it doesn't help you.

I don't want to think about how many rails user don't know this and send sensitive data to the client.

Edit: wouldn't have written this if I'd seen FooBarWidget's more detailed remarks first.

Ah, yes I see. I just found a benchmark that shows HMAC to be up to four times faster than Blowfish. Well, that explains things.

Ah, another reason to hold REST in contempt...

They could do without a (full) CC number there. Ergo, it's a violation.

It's simple defense in depth, and does reduce the risks - say, if the encryption you thought was secure really isn't, etc.