views:

404

answers:

7

When thinking about security and user experience, what information id OK, acceptable, or even a good idea to store in a cookie?

EDIT:


With the understanding that sensitive info, like user names, passwords, SSN, credit card numbers don't belong there, what does?

+4  A: 

One suggestion is that you not store any keys to your database in cookies. i.e. email addresses, column ID's etc. If so, you should encrypt the data.

madcolor
+2  A: 
  • User customization ID (a set of preferences stored in a db which you fetch on page load)
  • No personal information
dirkgently
+10  A: 

Definitely not passwords! Or anything sensitive... remember that cookies are stored on people's computers so from your point of view (as a website developer), they're basically out in the wild, potentially accessible to anyone.

A common practice is to just store a session ID in a cookie, and store all other relevant information in a database (or file, or whatever) on the server, indexed by session ID.

David Zaslavsky
+4  A: 

It's a lot easier to answer what's not acceptable to store in a cookie. Anything that should remain secure shouldn't be stored. That includes passwords, credit card numbers, social security numbers, etc.

I think it's okay to store a user's login name, since that information really isn't sensitive. A user's preferences settings for your site should be okay as well.

Remember, cookies are just plain text files that someone (or some application) can open up and read or write, so you shouldn't trust information you receive from a cookie, either. Sanitize it just like any other user input.

Bill the Lizard
+1  A: 

I would avoid storing anything that, if altered, would compromise the functionality of the site.

So, storing something like a user id, shopping cart items' prices, password, user roles, etc. are problematic. I keep this kind of thing in the user's session data on the server.

Storing a user's name or profile info (for display purposes only), customization preferences (colors, text, whatever) are fine.

BryanH
+1  A: 

Don't store anything in a Cookie that will allow your site to be hacked or accessed without going through proper channels. Usually, just a session ID or user ID is stored in a cookie, and often in a form intended to be opaque to anyone but the cookie consumer.

Eddie
+2  A: 

Well other than sensitive and security related data there really is no limit to what you can't and can store but just remember that if that data is not persisted on the server side, it could be lost altogether and it should be assumed that if the user deletes cookies, it won't inconvenience him too much to restore his settings/configuration. There are no guidelines other than using good common sense here.

There are however limits to cookies. You should not exceed 19 cookies per domain and no cookie should be bigger than 4KB (4096 bytes) as per IE limits:

Each cookie begins with a name-value pair. This pair is followed by zero or by more attribute-value pairs that are separated by semicolons. For one domain name, each cookie is limited to 4,096 bytes. This total can exist as one name-value pair of 4 kilobytes (KB) or as up to 20 name-value pairs that total 4 KB. If the computer does not have sufficient space to store the cookie, the cookie is discarded. It is not truncated. Applications should use as few cookies as possible and as small a cookie as possible. Additionally, applications should be able to handle the loss of a cookie.

If a Web application uses more than 19 custom cookies, ASP session state may be lost. Internet Explorer 4.0 and later versions allow a total of 20 cookies for each domain. Because ASPSessionID is a cookie, if you use 20 or more custom cookies, the browser is forced to discard the ASPSessionID cookie and lose the session.

aleemb