Can anyone provide any more solid details? This article seems to be a lot of hyperbole ("totally destroys") with little fact.
The error message provides a small tidbit of information about how ASP.NET decrypts messages. With enough of these error messages it is possible to decrypt the message in its entirety.
The HN thread consists basically of knee-jerking about "those waskly sekuwity wesearchers" and blatantly overtly false statements from people who had no business giving guidance about a flaw they knew literally nothing about.
As far as I can tell, this seems to allow you to decrypt the data within cookies. However, what would be stored within these cookies aside from a session ID? Some insight into what's actually stored in the cookie would be good, as this seems very overblown.
It would allow you to encrypt new cookies. The default authenticated cookies for ASP.NET forms auth is a username. If you can encrypt your own username/id values into your cookie, you can effectively make ASP.NET think you're logged in as whoever you want.
This notion of encrypted cookies or tokens being an inherently bad mechanism to store information securely is a red herring. The fact is that these platforms --- .NET, JSF, Rails, Django included --- provide functionality that stores encrypted information client-side. When that functionality is broken, it's a platform-level security flaw.
Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.
I'm inclined to disagree. Encrypted cookies should be secure, provided the underlying encryption techniques are solid.
There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others)
Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem.
Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password.
Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.
Comments
Can anyone provide any more solid details? This article seems to be a lot of hyperbole ("totally destroys") with little fact.
The error message provides a small tidbit of information about how ASP.NET decrypts messages. With enough of these error messages it is possible to decrypt the message in its entirety.
What message? The cookie itself?
It's a "padding oracle" attack, see tptacek's comment here: http://news.ycombinator.com/item?id=1687547
This is the whitepaper: http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf
I believe that's an older white paper.
Discussion on Reddit: http://www.reddit.com/r/programming/comments/df72k/quite_ser...
Someone want to sum this up for me? I'm genuinely afraid to click through that link.
It's a more hostile and verbose version of the thread here.
Guess what? Reddit outdid us on this one. james_hart in particular, but also a series of smaller clarifying comments. Look at this one:
http://www.reddit.com/r/programming/comments/df72k/quite_ser...
The HN thread consists basically of knee-jerking about "those waskly sekuwity wesearchers" and blatantly overtly false statements from people who had no business giving guidance about a flaw they knew literally nothing about.
Welp, the first comment was deleted. That completely changes the apparent tone.
As far as I can tell, this seems to allow you to decrypt the data within cookies. However, what would be stored within these cookies aside from a session ID? Some insight into what's actually stored in the cookie would be good, as this seems very overblown.
It would allow you to encrypt new cookies. The default authenticated cookies for ASP.NET forms auth is a username. If you can encrypt your own username/id values into your cookie, you can effectively make ASP.NET think you're logged in as whoever you want.
Honestly, if you're storing sensitive user information, or site access information in your cookies, then you deserve the resulting exploits.
I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.
This notion of encrypted cookies or tokens being an inherently bad mechanism to store information securely is a red herring. The fact is that these platforms --- .NET, JSF, Rails, Django included --- provide functionality that stores encrypted information client-side. When that functionality is broken, it's a platform-level security flaw.
Whether you're right or your wrong (and I would tend to agree that storing sensitive information clientside --- or doing anything else that involves encryption --- isn't worth the risk), this isn't a productive point to make. These designs exist, and can be secure, but contain flaws that must be corrected, lest many tens of applications be susceptible to devastating attacks.
I'm inclined to disagree. Encrypted cookies should be secure, provided the underlying encryption techniques are solid.
There are cases where having sensitive information in a cookie makes sense. In a web farm, for example. A session store that serves a farm of web servers is harder to set up and maintain than having clients send information back in a cookie. If it's properly encrypted, then this shouldn't be a problem. (Signed cookies are also good for this scenario, if it's okay for the data to be seen by others)
Am I wrong?
EDIT: Here's a good thread on how to ensure data on client cookies hasn't been tampered with: http://news.ycombinator.com/item?id=1687826
Storing something like a username in client-side data and then trusting its accuracy is effectively delegating your authentication outside you circle of control. Saying that encryption will make this magically secure is like saying encryption makes for effective DRM - eventually it will be compromised and you will have a systemic problem.
Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password.
Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.
It's not like DRM. Effective DRM is impossible because the client has to have the decryption key. All you can do is try to obscure it.
So the users login token is not "sensitive user information"?