ASP.Net MVC Cookies - Secure Against Unauthorized Access?

Question

So, I read a neat article that I found in / r / netsec:

https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly

One thing that really threw me into the loop is that you can flip a bit in an encrypted cookie and actually make a significant change to the data contained.

Make sure that all traffic passes through SSL, quite simply (this is not a matter of transport security), but it made me really think about the integrity of the messages and how to check if the original cookie was changed. Normally, I would only store the authenticated user ID in a cookie and handle everything else behind my firewall. What should I do if I can interfere with this cookie in order to change the client user ID? The above article shows that this is possible, and also offers suggestions for solving this problem, preferably using libsodium. I know about this library (I didn’t use it myself), but it leads me further down the rabbit hole when I think that I need something external for the ASP built-in security mechanisms.

Regarding the built-in ASP protection, do I need to do something special that has not yet been implemented in the standard way of protecting cookies (letting OWIN do its job or use FormsAuthentication.Encrypt)? If not, how is message integrity handled under the hood?

Further reading led me to this HttpSecureCookie class in the code project: http://www.codeproject.com/Articles/13665/HttpSecureCookie-A-Way-to-Encrypt-Cookies-with-ASP

The above indicates the use of a machine key to make evidence of cookie fraud, but I do not quite understand how exactly it makes it proof. How can this prevent an attacker from performing this reset of the bit specified in the original article into an encrypted cookie?

Answer 1

Just set the forms authentication method to Encryption and validation .

This will protect against bitflip attacks, since the signature will not match if the bit is turned upside down. Verification means that the message is signed.

How does validation work?

The verification algorithm can be set in web.config in the validationAlgorithm attribute of the machineKey element .

The default is HMACSHA256, which is a SHA-256 hash using HMAC .

The hash indicates a cookie - if the cookie value changes, the hash will no longer match. Since the end user does not know the secret, they cannot change the value of the cookie.

eg. Try here to generate a SHA-256 HMAC for the foo message using a secret secret .

This should give you: 773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4

Note that if you change foo to something else, the hash will be different. This way you can protect cookies from unauthorized access. This cookie will be set as follows.

 Set-Cookie: id=foo&hash=773ba44693c7553d6ee20f61ea5d2757a9a4f4a44d2841ae4e95b52e4cd62db4 

Note that the value is explicit, but the hash signature prevents any interference. This is just a test.

With the encryption and verification option, foo will be encrypted first, and the signature will prevent any bit switching. This allows you to store values ​​in a closed form from the end user.

If you implement this outside of forms authentication, remember, however, to save a certain type of expiration date in a cookie and include this in your signature. This date can be checked on the server side. Default Authentication does this by default.

Otherwise, the user may mark a valid cookie value. Say they are granted administrator access for one day and the following cookie is issued:

 username=admin&hash=71b3ba92493e92ce3c60042988e9de428f44b35a6be61c8da99fa43f950d3056 

The next day, when the administrator’s access is canceled, all the user needs to do is use the cookie editor to set their cookies to the above value, and they will gain administrator access to the system again.

To fix this, you will select the following cookie:

 username=admin&expiry=20150508100000&hash=e38a3a003b30ceb9060165d19bb8d2a2bca6c7c531a37e888448ca417166db3a 

It has an expiration date in the cookie that is signed in the hash. Any attempt to change the expiration date will result in an HMAC mismatch and the user will not have access. This will prevent any interference with the cookie expiration date or by any client resting party.

What are our other don't-mess-with-my-cookie options if you don't use forms-based authentication?

Another method is to save a completely random cryptographically secure generated string and set it as a cookie value. On your server, save the hash using SHA-2 (no salt is needed) and find this value to get information about the user's session. Of course, this has a few more overheads. The advantage is that sessions can be destroyed on the server side by deleting the record.

This can also be done using forms authentication, however you will need to implement a custom provider.