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?
asked Feb 2, 2016 at 15:52
-
2How will you know that you've correctly decrypted the cookie without it? You could decrypt to a random blob.– RoraΖ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?– Ilya ChernomordikFeb 3, 2016 at 8:37
-
1Why 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.– AndersFeb 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– Ilya ChernomordikFeb 3, 2016 at 9:10
-
@IlyaChernomordik hackingdistributed.com/2014/05/16/…– NatanaelFeb 3, 2016 at 12:37
Add a comment
|
2 Answers
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
answered Feb 3, 2016 at 11:47
-
How can a user manipulate encrypted data? (apart from making it garbage?) Feb 3, 2016 at 11:53
-
2They could incrementally try different bytes and then submit the cookie to your application to see if it works. e.g.
AAAAmight get a HTTP 500 response, thenAAAB,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. 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? Feb 3, 2016 at 11:56
-
1No, 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. 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) Feb 3, 2016 at 12:00
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.
-
How can a user edit the cookie if it's encrypted with a key not known to a user? Feb 3, 2016 at 8:37
-
1In 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.– MacilFeb 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 :)) Feb 4, 2016 at 8:23