Is it secure to store passwords in cookies? Is it secure to store passwords in cookies? asp.net asp.net

Is it secure to store passwords in cookies?


It's NOT secure to store passwords in cookies because they are available as plain text.

A good place to find some answers about cookies is Cookie Central. For membership usually is used a cookie with a long string called 'token' that is issued from the website when you provide your user name and password. More about the process you can find in this article.When using forms authentication in ASP.NET you can set the authentication cookie like this:

FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie);

The second parameter is used for "Remember Me" functionality - if true it will create persistent cookies that will last after you leave the site. You can also programatically manipulate the cookie like this:

HttpCookie authCookie =  HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName];


No! Don't store passwords in cookies!

In ASP.NET, use

FormsAuthentication.SetAuthCookie(username, true);

The second argument's value determines if the cookie is persistent (the remember me checkbox's value).


No, not remotely secure. You have no guarantee that cookies aren't stored in plain text (and in fact, most implementations do store them as plain text).

Mind you, "remember me" is inherently insecure, as anyone intercepting the cookie gets access to the application. But exposing a user's password takes it a step further down the insecurity ladder. :-) And probably makes the user really mad, if they find out.

I use an encrypted cookie string which incorporates the user's account name combined with a token that is in no (other) way associated with the user's account except in a table on my server. When the user returns to the site, we decrypt the cookie and look up whether that token is in fact associated with that account. The token (and therefore cookie) changes every auto-login, and invalidates the one used for that auto-login. (There's a many-to-one relationship between the tokens and the account, to allow for auto-login from multiple locations. You could limit that if you like.) Tokens time out if they aren't used within X days. (This is not only done by limiting the duration of the cookie; it's done server-side as well.) There are a few other things I throw in there to make life a bit difficult for someone trying to decode the cookie (having successfully decrypted it) or use a stolen cookie (which doesn't require decryption), but there's no point in going overkill (again, "remember me" is inherently insecure).

I use that on a site where robust security is not really necessary (obviously) and which has a large number of dynamic-IP clients, and so I don't try to lock it down to an IP. But even locking it down to an IP doesn't make it secure, it just reduces the attack surface a bit.

You may be wondering why I have the username in the cookie. For straight "remember me" purposes, I wouldn't recommend having it there, even if it is encrypted (after all, it's half of the authentication pair in a username+password system). I was a bit surprised to find it in our cookie when I looked at the format when reminding myself how we did this for this question; but then I saw the comments explaining why it's there and there are reasons unrelated to "remember me" (not necessarily persuasive reasons, in hindsight, but reasons).

On a final note, the fact that "remember me" is inherently insecure is one of many reasons why site logs are very important, and why you should require password reverification in the process of allowing changes to important account information (to make it harder for someone having stolen the cookie to take ownership of the account).