2

I have some sensitive data in the cookie, e.g. it contains the user id that is later on used to execute the query and we trust the cookie because it is encrypted. All communication happens only on https. Is it secure enough with just encryption, or I need to make sure that the cookie authenticity is maintained by e.g. adding MAC, signature or using authenticated encryption?

5
  • 2
    How will you know that you've correctly decrypted the cookie without it? You could decrypt to a random blob.
    – RoraΖ
    Commented Feb 2, 2016 at 16:07
  • But I encrypt the cookie myself using a key, then I will of course just decrypt it with the same key and it will be a random blob only if manipulated by a user? Commented Feb 3, 2016 at 8:37
  • 1
    Why do you even need to send the encrypted user id to the user? Send a random session id instead and keep the user id on the server mapped to the session id.
    – Anders
    Commented Feb 3, 2016 at 8:51
  • Because I don't want to have any state on the server, but otherwise it is not really important what type of sensitive data is in the cookie for the scope of this question I guess Commented Feb 3, 2016 at 9:10
  • @IlyaChernomordik hackingdistributed.com/2014/05/16/…
    – Natanael
    Commented Feb 3, 2016 at 12:37

2 Answers 2

5

Yes you need a MAC in order to ensure the user hasn't manipulated the value to something else which is a valid user id once decrypted.

Also, rather than MAC <userid> you should add some context around it, and then mac that.

e.g. userid=<userid>

This will prevent a substitution attack elsewhere on your site with data that has been MAC'd. For example, if there's a page on your site that an attacker needs a MAC'd 100 to pass to it. e.g.

example.com/view_order?order_id=100&mac=****

The attacker does not know the MAC to input. However, the user can create users and their recently created user has user ID 90. The attacker simply creates 10 more users and has a look at the created cookie. As this will contain the MAC for the number 100, they can then substitute in the value to their URL request above. This is why context matters when creating MACs.

Additionally, you should ideally include an expiry date on such data to prevent replay attacks at a later time.

e.g. you should mac userid=<userid>&expiry=20160203120000

7
  • How can a user manipulate encrypted data? (apart from making it garbage?) Commented Feb 3, 2016 at 11:53
  • 2
    They could incrementally try different bytes and then submit the cookie to your application to see if it works. e.g. AAAA might get a HTTP 500 response, then AAAB, AAAC, etc until a HTTP 200 code is retrieved. With a MAC, they would also need to ensure that this matches too, which is an infinitely larger task. Commented Feb 3, 2016 at 11:55
  • But doing this incrementally different bytes successfully will mean that they have broken the cipher's semantic security (e.g. AES), isn't it? Commented Feb 3, 2016 at 11:56
  • 1
    No, the output of AES doesn't have any semantics. That's why you need a MAC. Some encryption ciphers do though (e.g. GCM), as they inherently authenticate data using their own MAC. Commented Feb 3, 2016 at 11:58
  • Ok, I see, thank you. Could you please explain a bit more around the context, I did not quite get about the substitution attack that you mentioned (I do have this format anyway just because of structure, but still interested) Commented Feb 3, 2016 at 12:00
2

HTTPS only prevents 3rd parties from doing man-in-the-middle attacks and manipulating the connection (including the cookie). HTTPS does not do anything to protect you from a malicious user. The user could edit their own cookie. You need to use authenticated encryption or sign the cookie's contents yourself if you don't want the user to try to edit the id in their cookie to a different user's id.

3
  • How can a user edit the cookie if it's encrypted with a key not known to a user? Commented Feb 3, 2016 at 8:37
  • 1
    In some encryption systems, flipping a bit in the ciphertext will cause the same bit to be flipped in the plaintext when it's decrypted. A user could change the ciphertext at random to guess at other users' id numbers, or if the user knew their own id number, they could modify their own ciphertext to decode to any number of their choosing.
    – Macil
    Commented Feb 3, 2016 at 22:38
  • Yes, I got it know after SilverlightFox explained that to me in the comment, but it was not clear in your answer (or I did not understand it fully without explanation :)) Commented Feb 4, 2016 at 8:23

You must log in to answer this question.

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