[pillock]

> Maybe I'm an ignoramus, but what's wrong with storing your credit card number in a cookie, as long as it's encrypted? This is how session management is typically done, right? Your session information is stored encrypted in a cookie so that on subsequent page requests, the server still knows who you are, but the session information is encrypted and decrypted on the server, so that the client can't forge the session information.

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.

[dgoodlad]

That's how _some_ session tracking works. See Rails' CookieStore strategy for session storage for example: http://guides.rubyonrails.org/security.html#session-storage

> 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:

[chris_wot]

That's not how secure session management works.

[cheald]

It's plenty secure in the sense that you can't forge a session. It's not secure in the sense that the data is inaccessible if you know how to base64 decode a cookie.

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

[chris_wot]

In other words, because they are holding sensitive information in their cookies encoded only via base64 it's not secure. In other words, what I said.