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.
Comments
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.