7

I am curious how one decides whether to encrypt cookies or not? And if so when should one use public private key over symmetric encryption?

2
  • Possible duplicate security.stackexchange.com/questions/67401/… Commented Feb 11, 2016 at 22:24
  • 1
    Considering that each implementation of encryption is a potential failure, since it is so often done badly even by experts. I'd consider twice all decisions that lead me to have so sensitive information in cookies that I'd have to encrypt them.
    – Simply G.
    Commented Feb 12, 2016 at 7:04

3 Answers 3

9

If they contain sensitive information and you have no other solution than sending it in a cookie (you very likely don't). The pub/priv key model would not work easily within a browser, and would most likely not accomplish what you're trying to do.

Really you should not include any sensitive information in a cookie, and ones that do contain state data which you do not want modified should be signed using something like HMAC using a secret known only to the server.

5
  • 1
    Wouldn't a HMAC imply symmetric encryption, so the secret key must be shared? And why wouldn't pub/priv key model not work easily in the browser? Commented Feb 12, 2016 at 3:17
  • 2
    @whatever489 Who is it you want to share the secret with?
    – deviantfan
    Commented Feb 12, 2016 at 6:27
  • @deviantfan well no one really. Because if some malicious guy has access to y cookies, what is stopping him from having access to the AS key? So I was thinking PPK encryption and then even the client wouldnt know what is in the cookie. Commented Feb 12, 2016 at 12:05
  • @whatever489 The idea was not to put the key into a cookie.
    – deviantfan
    Commented Feb 12, 2016 at 16:07
  • 2
    HMAC is indeed symmetric, but the client does not need the ability to re-sign. This allows the server to use the same key to sign and validate the signature, and the client has no ability to sign. Pub/Priv doesn't work easily because this isn't a built-in mechanism the browser provides (beyond SSL/TLS for HTTPS) so you would need quite a bit of JavaScript to get this to work smoothly, and the use-cases that would require this model are pretty limited when dealing with most web-based applications.
    – Vetsin
    Commented Feb 12, 2016 at 18:16
4

You should encrypt cookies by making them secure (only sent over HTTPS). There's really no reason to manually encrypt data with server side RSA/AES or similar or browser side RSA/AES. If you attempt it, you'll probably leave open vulnerabilities in your implementation, identification, and key exchange protocol.

Your cookies should only contain information that you don't care if the browser at the other end sees or tampers with. You use transport layer security (TLS) to ensure that network eavesdroppers can't see your cookies or tamper with them.

If you have secrets that need to be associated with the user, you should store those secrets server-side and associate them with the user through a either:

  1. random session token that's long enough to be unfeasible to guess (e.g., 128 bits),
  2. session token generated via an HMAC generated server side on login with a server-side secret that identifies the user. This session is checked server side everytime a secret needs to be used. Something like HMAC(username+login_timestamp, key = server_side_secret) where you essentially hash a combination of the users information with the server side secret key. Then you can associate secrets with the username and before using the secrets, verify that the session token is valid by checking the HMAC is valid. So an attacker who alters their username (to someone else's) or changes the login date (to avoid automatic logout) can't pretend to be a valid signed in user.
3
  • 2
    Completely disagree. Sessions are a poor man's attempt to recreate a connected client/server model in an inherently disconnected protocol in which they do not belong. This doesn't scale, doesn't fit the HTTP architectural model, and is generally poor advice.
    – Xander
    Commented Jan 18, 2017 at 21:02
  • 3
    @Xander so you don't agree but you also don't have other solutions. Also the point that it does not scale is untenable. The whole web relies on tokens (for example oauth2) - it just moves the data to a trusted storage that could scale as well.
    – iRaS
    Commented Apr 19, 2020 at 21:48
  • Must say that the debate of maintaining session cookies vs. not to - is a famous debate. you will find on the net both arguments (supporting and against session cookies)
    – Mercury
    Commented Sep 8, 2022 at 7:28
2

Ah cookies. Little bites of delicious information from a web server. This technology has been around for a long time, is tried and true, and works very well if implemented correctly.

Now I say if implemented correctly, and there is a reason for that. Cookies contain information. Keeping secret information secret is a top priority. If that information isn't secret anymore, something bad can happen. This leads to the easiest way ever to decide if a cookie should be encrypted:

Does this cookie contain sensitive information?
Yes: ENCRYPT
No: Whatever

So how should you encrypt the cookie? Well that depends on the type of cookie:

Session/Server Side Only: Never let the user modify it(private, done on server only)
Private user data: symmetric, secure encryption so that the user can use the information inside of it

After that it's all about checking to make sure you're using the correct algorithms to encrypt your data securely, and have enough checks and balances to make sure they aren't tampered with(think JWT)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .