What are the risks of storing a user password in a Cookie, when the connection is via https?

Question

A Note

I have a very good understanding of sessions and the theory of secure web-based authentication, etc., so please don't start with the basics, or give ambiguous answers. I am not looking for Best Practices, because I am aware of them. I am looking for the real risks behind them, that make the Best Practices what they are.

I have read, and agree with the principals that nothing more than a Session identifier should be stored in a Cookie at any given time.

The Story

However... I've inherited a rusty old app that stores the Username, Password, and an additional ID, in a Cookie, which is checked throughout the site as verification/authorization.

This site is always (can only be) accessed via HTTPS, and depending on your stance, is a "low-risk" website.

The application, in its current state, cannot be re-written in such a way as to handle Sessions - to properly implement such a thing would require, essentially, re-writing the entire application.

The Question

When suggesting to the-powers-that-be that storing their user's IDs/Passwords in plaintext, in a Cookie, is an extremely bad idea, what real risks are involved, considering the connection is always initiated and manipulated via HTTPS?

For example: is the only obvious way to compromise this information via Physical Access to the machine containing the Cookie? What other real risks exist?

Answer 1

Some other risks include cross-site scripting attacks which can enable cookie theft and who knows what kind of browser vulnerabilities which can enable cookie theft.

Answer 2

Some browsers keep cookies in a file that can be displayed on the computer. IE6 comes to mind. It seems to me that cookies are not all that restricted to a single site. Lots of advertising uses cookies across multiple sites. If I go to NextTag and look for a Nikon D700 camera then I see NextTag advertisements on slashdot.org. This is an example of a cross-site cookie. Most users use the same password all over the web so if you store the password to one site and make it even a little easy to get to then malicious folks will sooner or later get to it.

To summarize this would be a very very very bad idea. On sites that I work on we don't save users passwords at all. We convert them to a hash key and save the hash key. That way we can validate the user but if we loose the content then there is no exposure of passwords. And this is on the server side, not the browser side!

Answer 3

HTTPS just protects against a man-in-the-middle attack by encrypting the data that goes across the wire. The information would still be in plain text on the client. So anything on the client's computer can go through that cookie information and extract the pertinent information.

Answer 4

A given browser's "cookie jar" might not be stored securely, i.e., an attacker might be able to read it without physical access to the machine, over a LAN, or from a distributed filesystem (e.g., if the machine's storing user homes on a storage server, to allow for roaming), or via an application running on the machine.

Answer 5

Two two main vulnerabilities are cross site scripting attacks and someone accessing the user's machine.

Have you thought about just storing a password hash in the cookie instead of the raw password? It would require some coding changes but not nearly as many as swapping out your entire authentication system.

Answer 6

People here already mentioned the "man in the middle" attack. The thing is that even with https it is still possible. There are different ways to do this - some of them relay on physical access to the network some of them do not.

The bottom line here is that even with https it is still possible for somebody to insert itself between your app and the browser. Everything will be passed through and will look from the browser exactly the same EXCEPT the server certificate. The intruder will have to send his own instead of the real one.

The browser will detect that there are problems with the certificate - usually it will either be issued to a different dns name or, more likely it will not be verified.

And here is the problem: how this violation is presented to the end user and how end user will react. In older versions of IE all indication of the problem was a small broken lock icon on the right side of the status bar - something which many people would not even notice.

How much risk this introduces depends on what is the environment and who (how trainable) the users are

Answer 7

Most cookies are limited time credentials. For example, session identifiers that expire after a couple hours or are forgotten when the browser windows. Even if the attacker gains access to the session cookie, they are guaranteed neither continued access to the account nor the ability to prevent the original account holder from logging in. Preventing long term account compromise is one of the reasons users are asked for their old password before being allowed to enter a new one.

A cookie containing a username and password, if disclosed, is much longer lived. Also, many users share their passwords between websites. As others have pointed out, the cookie could easily be disclosed via Cross-Site Scripting.

Finally, is the cookie marked with the "Secure" flag? If its not, an active network attack can easily force the browser to disclose it, even if HTTPS is used to serve the entire site.