views:

1190

answers:

9

Hai guys,

My web application's home page has a RememberMe checkbox.. If the user checks it, i ll store emailId and password in cookies.. My code is

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

Now i want to know,

  • Is it secure to store passwords in cookies?

  • What is ur way of doing the same?

  • what are the best practices in setting time for a cookie?

+22  A: 

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];
Branislav Abadjimarinov
Indeed. It is never secure to store passwords anywhere. Only ever store a hashed version and check against that.
Matt Ellen
You don't even need a hashed version here (and avoid it because that has its own risks, e.g. lack of salt). An arbitrary token that has no mathematical relation to the userid is sufficient - the only party that understands the token is your login service, and it checks the token by a DB lookup.
MSalters
+6  A: 

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.

naivists
+15  A: 

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

Ralph Stevens
A: 

It is not at all secure. Cookies are stored in the client computer, which can be tampered with.

Bhaskar
+5  A: 

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

T.J. Crowder
A token that changes on every login would prohibit an auto login to the same account from different locations ("home" and "work") or from different browsers.
Hans Kesting
@Hans: Only if you only allow a single token per account. If you allow a many-to-one relationship between the tokens and the user accounts (I do, via a tokens table) the user can have multiple auto-logins active. I'll update the answer to make that clearer and to mention timeouts.
T.J. Crowder
+2  A: 

It's not secure to store passwords in cookies cause they are available as plain text. but if your preferred criteria is to do so or any user requirement is there you can do so by encrypting the strings. that can make this safe enough.

but it is not recommended,

moon
+2  A: 

I think you need to create a token with username and an encrypted authentication string which you get from windows Identity. No need to store password on cookie. We have our application which stored username and authenticated string

jalpesh
A: 

Btw, store passwords isn't secure everywhere, both client and server-side.

You don't need to do that.

Nikkau
A: 

You might consider using this little open source library:

http://www.codeproject.com/KB/aspnet/Univar.aspx

It is can automatically encrypt your cookies in one line of code. It comes with many other goodies as well. For example it can store all your cookies on the server instead and use the client cookie for identification purposes only.

Ziad