Is It Secure to Store Passwords in Cookies

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];

PHP - Is it secure way to store password in cookie?

Why do you need to store the password in the cookie? Why not some other user identifier, such as an internal user ID or some temporary value of some kind?

"Store" and "password" are two words that should very rarely be used together, and when they are that use should be scrutinized carefully.

What information is OK to store in cookies?

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.

Is it secure if I store a sha1 password and a userID in secure flag & https Cookies?

Is it secure if I store a sha1 password and a userID in secure flag &
https Cookies?

No.

I suppose you want to know why? First, define "safe." What threat are you trying to mitigate?

Once the credentials are hashed, there's no way to get the plaintext back. Since you can't render the hashed string back to plaintext then we can assume that the intent is to compare them to the same hashed string held at the server, yes? That's awesome if the threat you want to mitigate is somebody discovering the password and user ID and you use something like SHA256 instead of SHA1.

But if the threats you want to mitigate include replay attack or session hijacking, then these are no better than any other fixed string. In fact they are worse. If the user is obliged to provide their password for each HTTPS request it sucks for them but at least the app can throttle login attempts and foil a brute force attack. If the credentials are hashed and exchanged in cookies, then they are exposed to adversaries and if obtained can be subjected to brute force cracking or looked up in a rainbow table so on net sending the credentials back out, even encrypted or hashed, kinda sucks.

The question doesn't mention salt or session keying. An adversary will look at the cookies to see identical values are returned over multiple sessions. To prevent replay attack you'd need to append a nonce before hashing to act as a salt so the hashed string changes each time. But it doesn't solve the problem of sending a transformed credential pair outside of control of your own server or that this is far worse than just using a long random string for the same purpose.

Furthermore, the hash of the credentials doesn't time out until and unless the user changes their password - at which point it tells an adversary that the user just changed their password which is a great piece of info with which to social engineer the IT support person who does password recovery. "Hi, I just changed my password and locked the account. Can you reset it? Employee ID? Well if I had access I could look it up. Can you just reset it? I'm really me. How else would anyone I know I just changed it?"

The support person would never guess the answer to that question is "because Victor's app design told me it was just changed" and might just reset it for the adversary. But if the session is kept alive by a session cookie or a triparte login token then the unique string representing that user's session mitigates all of the threats discussed so far:

• An attacker can't reverse it or crack it to discover credentials because they aren't in there.
• It can't be used for session replay since it is generated to be unique for each session.
• It expires within a short period of time so it can't be resurrected from browser cache or history.

But rather than answer the question as asked, I'd like to answer the question "Is there an authoritative source for comprehensive web application security best practices?" That's a much easier question to answer and it potentially answers your initial question if you follow through with the required study.

Please see: Open Web Application Security Project (OWASP).

In particular, please see the Session Management Cheat Sheet and the Authentication Management Cheat Sheet as these cover much of what you are trying to do here.

OWASP periodically analyzes all reported breaches for a recent period and then publishes the Top 10 Vulnerability List based on the root causes that showed up most often during the sample period. When I QA new web sites on behalf of clients they almost always have several of the defects in OWASP's Top 10 list. If as a developer or web site development company you want to stand head and shoulders above the crowd and get a lot of repeat business, all you need to do is make sure the site you deliver doesn't have any defects in OWASP's list. The question suggests any application built as proposed would have at least 4 or 5 defects from the OWASP Top 10 so that's an aspirational goal for now. Aim high.

Does plainText password over https remains secure when stored in the client.?

You probably don't want store the password.

What you need is store some "user is already authenticated" flag.

After all, you should learn about "digest access authentification". Storing hashed data is always plus.

This answer is too short, mainly bacause here is too much possibilities - and too much open questions.

Handling returning users:

You can manage (server side) an session database. in the cookie you storing only session ID. when the user authenticate itself, you're store into your server side database his status: "logged in". when he log out, you change in the DB status: "logged off".

Handling returning users has nothing with "storing passwords" in any way. You for example can authenticate users by external auth-services, like open-id, twitter, facebook etc., you're only storing his status by some session-ID or similar.

Browsers usually can store user-names/passwords, but this all time should be the user responsibility. When the user want only remeber his passwords, you should not store it in any way.

Why you want complicating your app and security mechanisms with storing encrypted passwords in cookies - what is not a correct solution - from any point of view?

Simple flow:

• When an new user comes to your site - you assign him an new session-ID and store the SID into a cookie
• when he login (via https) - you're store in your DB = "sessionID" -> "logged in"
• when he return after a week, you can (server side) either accept his session-ID from the cookie - and from DB you can get his "logged-in" status, or, you can force login him once again (for example because of expiration)
• all of the above is without any risk storing passwords in any way

How to store cookies containing sensitive data securely in PHP?

Don't store the password in the cookie, hashed or not. In fact, there's no reason to store anything sensitive in the cookie. All you need to do is map a 128-bit (or larger) random id to a user account in your database, and store that id in the cookie. There is no way somebody is going to guess a valid id by remote brute force, especially if you have lock-outs in place.

If someone were to gain access to the cookies and they copy them to a different computer, and then try accessing the website from that computer, theoretically, it will automatically log them in to that user's account, is this not a security issue?

Yes. That's the downside to the feature. However, if your website detects new IP address (particularly from different countries) and requires a second step (text a code to a mobile device, etc), then you take care of this problem along with the general problem of a stolen password. (This of course doesn't help prevent local network attacks, like an insecure public wifi.)

A more convenient solution is to require the "remember me" cookie to use SSL. That way a hacker would not ever see the cookie in plain text transmission, and a local attack would probably be required. (And if such, the remember me cookie is probably the least of the user's concerns.)

they can effectively get access to any account they want, rendering the whole password-hashing process as useless.

Yes, and no. If you use the technique I described (random id) then they can only access accounts that have a "remember me" cookie. But that said, if they have access to your database, they can brute force any account they want. Even salted passwords are easy to crack locally if the password itself is weak.

Also, you can consider the "remember me" login to be a half-login. Access to purchase something, change an email address, etc, would still require a password to be entered. Doing harmless things like posting on a message board could be done without the password.

Finally, note that a PHP session cookie is nothing more than a temporary "remember me" token! So much of this applies to the concept of session hijacking. The "remember me" token simply adds a bigger window of opportunity.

So in short: don't store anything sensitive in the cookie, require SSL for the cookie, and if possible, implement multi-factor authentication ... especially for admin accounts.

---

Related Topics