Hacker News Reader

Comment by icey | Hacker News Reader

What are potential solutions to this? Keep a KV store of ids and checksums of every cookie sent and verify them when requesting the data back from the client?

View on HN

Make sure fat cookies are MAC'd AND CBC-encrypted, decrypt, always check the MAC, generate indistinguishable errors for the MAC failure and the padding failure, and expire sessions associated with bad decryptions or MAC failures.

Nate Lawson actually suggests encrypt then MAC. See http://rdist.root.org/2010/09/10/another-reason-to-mac-ciphe... which was spawned by http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....

Encrypt-then-Sign addresses this problem, but it's a design change, and it's not the case that Encrypt-then-Sign is an industrywide best practice (Practical Cryptography, for instance, recommends the opposite).

I think it depends on the encryption and signing algorithm implementation as to what works best, but then again I deal with app security and am not a cryptographer.

Encrypt-then-sign prevents the padding oracle attack; a 1 bit change to the input will immediately fail the MAC verification, preventing attackers from generating the repeated trials they need to exploit the padding error.

This doesn't depend on the algorithms you use. The padding oracle attack works just fine with DES-EDE, Serpent, AES or Twofish; HMAC-SHA1, HMAC-SHA256, and (probably) HMAC-MD5 are all equally effective at combating it.

I was thinking more about the problems with MD5, but you're right, thanks for the comment.

I believe the real solution to this problem is to not encrypt the cookies at all, but rather just use HMAC to make sure no-one can tamper with them.

If you need to put sensitive data in cookies, you're doing it wrong!

The only thing that sticks out in my mind as being a potential issue is user IDs.

The train has already left the station on encrypted fat cookies. It's not productive to argue that the problem is fundamental to the design; it isn't. This is the textbook definition of an implementation fault.

Note that (a) lots of people have screwed up HMAC recently and (b) HMAC isn't a solution to the padding oracle problem unless you take pains to make sure it isn't.

Regardless of the issue mentioned in this article, it could be argued that encrypting cookies, which basically means that you're storing data on a user's computer which the user is not allowed to even look at, is a flawed idea. If the user should not be able to look at it, why store it at the user's computer in the first place? And why must the app hide the data for the user?

(Unless I'm mistaken and there's other advantages for choosing encryption over MAC?)

Interesting, how could you exploit padding oracle when you're using HMAC?

You need to do both: encrypt to provide confidentiality, MAC to provide integrity.

In sign-then-decrypt designs --- which, from what I've seen, is what most designs are --- you can still exploit a padding oracle when the app catches padding errors and skips the (pointless) MAC verification for a packet it plans to discard anyways.

So wait - this is about clientside cookies that a developer would knowingly choose to write versus something that is just automatically happening behind the scenes with asp.net? Aka, if you never write any cookies - encrypted or otherwise - then this doesn't apply to you or your app?

I don't know ASP.NET at all, but this is the way I understood the article:

If a developer writes a cookie, it's not encrypted and the user can easily change it. Just normal cookies.

If a developer writes a session cookie, ASP.NET encrypts it behind the scene and stores it in a cookie. Because the user doesn't know the encryption key, he can't change the session cookie. The developer doesn't do any encryption himself, he just tells ASP.NET "Please store this value at the user, but he should not be able to tamper with it".

However, crypto is hard, so because of the issue mentioned in this article it is possible to tamper the data.

Could someone correct me if I'm wrong?

All anyone "officially" knows right now is that there is some place in ASP.NET where the stack uses AES/CBC to encrypt data that is then passed back and forth with clients, and that place failed to prevent padding oracles. 'brl is close with Juliano Rizzo, and downthread he suggested that this flaw allows attackers to 100% effectively forge authentication credentials on any ASP.NET application.

Reply on news.ycombinator.com