Is it secure to store passwords in cookies?

My web application's home page has a RememberMe checkbox. If the user checks it, I willl store email-id and password in cookies. This is my code:

if (this.ChkRememberme != null && this.ChkRememberme.Checked == true)
   {
     HttpCookie cookie = new HttpCookie(TxtUserName.Text, TxtPassword.Text);
     cookie.Expires.AddYears(1);
     Response.Cookies.Add(cookie);
   }

What I want to know is:

• Is it secure to store passwords in cookies?
• What is proper way of doing the same?
• What are the best practices in setting time for a cookie?

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).

This is what you should never do, because it is very easy to change the value of a cookie and send back to server. Even storing "user is looged in as 'naivists'" in a cookie is wrong, because I could then change it to "user is logged in as 'Pandiya Chendur'".

What you can do in cookies is give information to clients that, even if changed, does not make sense to the server. For instance - favourite color, first page layout et cetera.

You may give them session ID which is stored in a cookie, because they cannot make anything better for themselves, if they change the value to something else (unless they know a valid session ID from another session).

What Microsoft's MSDN says about using cookies:

The security issues with cookies are similar to those of getting data from the client. In your application, cookies are another form of user input and are therefore subject to examining and spoofing. A user can as a minimum see the data that you store in a cookie, since the cookie is available on the user's own computer. The user can also change the cookie before the browser sends it to you.

You should never store sensitive data in a cookie, such as user names, passwords, credit card numbers, and so on. Do not put anything in a cookie that should not be in the hands of a user or of someone who might somehow steal the cookie.

Similarly, be suspicious of information you get out of a cookie. Do not assume that the data is the same as when you wrote it out; use the same safeguards in working with cookie values that you would with data that a user has typed into a Web page. The examples earlier in this topic showed HTML-encoding the contents of a cookie before displaying the value in a page, as you would before displaying any information you get from users.

Cookies are sent between browser and server as plain text, and anyone who can intercept your Web traffic can read the cookie. You can set a cookie property that causes the cookie to be transmitted only if the connection uses the Secure Sockets Layer (SSL). SSL does not protect the cookie from being read or manipulated while it is on the user's computer, but it does prevent the cookie from being read while in transit because the cookie is encrypted. For more information, see Basic Security Practices for Web Applications.

• If you use SSL which you should if you are transmitting any secure information, that eliminates a third party from listening to your web traffic. This would be the same issue regardless of storing a users credentials in a cookie because when they login your sending their username and password to the server anyway, where I assume the server hashes it and compares it against the hashed password you have for that user.

• Other domains will never be able to read your cookie because of cross-origin so that's not an issue.

• So really the only "security hole" if you want to call it that is if someone physically gains access to their computer. If that happens they're most likely going to get any information that want from that person anyway. How do you explain when chrome auto fills out login forms for you, is that secure? I'm sure they are not storing it in plain text but that doesn't even matter. If you go to a page that chrome auto fills you can just copy the password out of the form and look at that you now have that persons password.

• It really comes down to how "secure" you need it to be. I agree that encrypting a users information with an expiration as a token is the best way to authenticate service calls and it provides flexibility. I just do not see the issue with storing login credentials in a cookie.