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?

whatever489
  • 838
  • 3
  • 9
  • 21
  • Possible duplicate https://security.stackexchange.com/questions/67401/what-is-actually-the-purpose-of-encrypting-the-values-in-a-cookie – user2320464 Feb 11 '16 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. Feb 12 '16 at 07:04

3 Answers3

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.

Vetsin
  • 326
  • 1
  • 3
  • 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? – whatever489 Feb 12 '16 at 03:17
  • 2
    @whatever489 Who is it you want to share the secret with? – deviantfan Feb 12 '16 at 06: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. – whatever489 Feb 12 '16 at 12:05
  • @whatever489 The idea was *not* to put the key into a cookie. – deviantfan Feb 12 '16 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 Feb 12 '16 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.
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 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 Jan 18 '17 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 Apr 19 '20 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 Sep 08 '22 at 07: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)

Robert Mennell
  • 6,968
  • 1
  • 13
  • 38