3 ms·

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 nee

by judofyr 16y ago

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!

icey 16y ago
The only thing that sticks out in my mind as being a potential issue is user IDs.
tptacek 16y ago
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.
- judofyr 16y ago
  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?
  - tptacek 16y ago
    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.
evo_9 16y ago
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?
- judofyr 16y ago
  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?
  - tptacek 16y ago
    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.

by judofyr 16y ago

icey 16y ago

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

tptacek 16y ago

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.

judofyr 16y ago
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?
- tptacek 16y ago
  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.

evo_9 16y ago

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?

judofyr 16y ago
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?
- tptacek 16y ago
  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.