If cookies are stored in plaintext, then any program which has read access to the cookie file can hijack the browser session, which is bad. However, even if cookies are encrypted, the browser must have enough information to decrypt to actually use them. It doesn't look like the browser fetches that information from remote every time it wants to decrypt a cookie? But if that information is stored locally, then any program having access to it can decrypt the cookie as well. How is cookie encryption helpful in this case?

Edit: This question is not about server-side cookie encryption. See this commit for background.

  • 2
    Encrypted cookies are not used by the browser, but by the application on the server side. – ThoriumBR Jul 1 '18 at 16:43
  • @ThoriumBR What does this mean? And how is this related to the question? Still can't see where the user benefits from encrypted cookies. – Cyker Jul 1 '18 at 17:05
  • It means that the application encrypts the cookie and send to the browser. The browser don't need to use the cookie, it only need to send it back on every request. – ThoriumBR Jul 1 '18 at 19:23
  • Exactly. The cookie, in this case, is an opaque envelope that the browser and server pass back and forth. The browser never knows what is in it, nor does any other JavaScript that gets loaded or injected into the page. – Craig Jul 2 '18 at 1:32
  • @ThoriumBR Well I know the server can do something on the cookie to prevent client-side tampering. But it seems encryption also happens on the browser side: See this commit. This is a different topic and is what actually confused me. – Cyker Jul 2 '18 at 3:02

After your edit, the question is about something entirely different.

That commit is about encrypting the cookie database with an user-specific key, for Windows' users. On a multi-user Windows environment, it's common for a user to have access to other users' files. Encrypting the cookie database with a key held on the user registry and derived from user password, other users cannot access that data.

This increases cookie security, because any attacker getting the database file will not be able to read the cookies. To read the data, the attacker must get the computer while the user is still logged in, or compromise the password.

But the cookie database is not as valuable as the saved password storage.

  • I didn't quite understand this: ... it's common for a user to have access to other users' files .... If it's common for one user to access another one's files, why wouldn't it be common for one user to access another one's registry, and get the key, and decrypt the cookie database, and get the cookie? – Cyker Jul 3 '18 at 2:59
  • 1
    You usually don't have access to another user's registry keys unless you are an admin. – ThoriumBR Jul 3 '18 at 13:21
  • Users wouldn’t have access to each other’s files, either, if file permissions were done right. But they often aren’t. And you can’t really claim that Unix/Linux solves this problem, either, since any user with root access can read any file in the system. A hard drive/SSD can just be pulled and attached to another system where you have root. In this sense, Windows is actually MORE secure than Linux if it is hardened. – Craig Jul 9 '18 at 5:01
  • Linux with Full Disk Encryption, or at least with home folder encryption, is as strong as the password for the encryption. My Linux is fully encrypted, so even if someone steals my computer or my disk, cannot read anything on it. – ThoriumBR Jul 9 '18 at 12:45

The primary purpose of cookies is to store client information for server. Without cookies server would have to deal with following problems:

1. Identify the client. Signing in at every possible web site is impossible. Identification via other means (user agent, screen resolution, canvas fingerprint etc.) might identify the client, but not 100% reliable.

2. Store some information about the client. It was more important at the beginning of Internet. Now storage is relatively cheap and for many web sites the amount of storage for cookies even for millions of clients is not a big problem.

Client code in a good application normally doesn't have logic that depends on information in cookies. Any data that client needs is normally delivered either within the content (HTML, CSS, JavaScript) or by a service call, e.g. client makes an AJAX or REST call and retrieves needed information from the server.

That is why in a application with good architecture client logic does not depend on cookies contents and thus client does not need decryption of cookies.

Encrypted cookies give normally false feeling of security. When an attacker gets access to your file with cookies, he can copy them and use in the browser. Server will receive correct cookies, decrypt them an will not be able to distinguish, if cookies come from you or from attacker.

Encrypted cookies have a huge disadvantage, because they make for user impossible to check what information is saved in the cookies. Users think that the web site is collecting some information that the users might not like and makes this information unreadable for user. Thus encrypted cookies make web sites suspicious.


I think self destructive cookies would be a better way to enhance browser security. Luckily you can do this with many popular browsers already with a simple add on. Optionally you can also set most browsers to not save cookies to disk or wipe cookie history on close.

If your paranoid you can simply block cookies, thereby foregoing both cookies and the encryption argument altogether. Also there is no way to guarantee end to end encryption between server/client, which was one of the hot topics of the nineties.

It can't be resolved the problem has more to do with server side than client side, its like walking into a store and demanding they except certified cheques. You could probably pull that stunt off with a couple of popular places but that's it. Just because you carry a certified cheque doesn't guarantee the place you shop at would except it. Similar scenario with cookies.


This should be a comment, but its a bit long.

If cookies are stored in plaintext, then any program which has read access to the cookie file can hijack the browser session

This statement only makes any sense if you are suggesting that that data sent by a server in the form of a cookie should be encrypted by the browser before being committed to non-volatile storage. The contents of the cookie may already have been encrypted elsewhere. It pre-supposes that cookies will be written to disk (not necessarily) and that the browser and OS do not enforce strict locking or that the cookie persists between browser sessions. That's a lot of unstated assumptions.

If any of these were not implied in your question then it make no sense.

A competent programmer will use session cookies, random identifiers and server side data in the right mix to protect the application; it would be dangerous to make assumptions about the implementation details of browser not specifically documented as requirements. Perhaps you could point us to the W3C specification for encrypted cookies you are referring to?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.