I&#39;ve just read on the net about a newly discovered security vulnerability in ASP.NET. [You can read the details here.][1]

&gt; The problem lies in the way that
&gt; ASP.NET implements the AES encryption
&gt; algorithm to protect the integrity of
&gt; the cookies these applications
&gt; generate to store information during
&gt; user sessions.

This is a bit vague, but here is a more frightening part:
 
&gt; The first stage of the attack takes a
&gt; few thousand requests, but once it
&gt; succeeds and the attacker gets the
&gt; secret keys, it&#39;s totally stealthy.The
&gt; cryptographic knowledge required is
&gt; very basic.

All in all, I&#39;m not familiar enough with the security/cryptograpy subject to know if this is really that serious.

So, should all ASP.NET developers fear this technique that *can own any ASP.NET website in seconds* or what?

How does this issue affect the average ASP.NET developer? Does it affect us at all?
In real life, what are the consequences of this vulnerability? And, finally: is there some workaround that prevents this vulnerability?

Thanks for your answers!


----------


EDIT: Let me summarize the responses I got
----------------------------------------

So, this is basically a &quot;padding oracle&quot; type of attack. [@Sri][2] provided a great explanation about what does this type of attack mean. [Here is a shocking video about the issue!][3]

About the seriousness of this vulnerability: Yes, it is indeed serious. *It lets the attacker to get to know the machine key of an application.* Thus, he can do some **very** unwanted things.

- In posession of the app&#39;s machine key, the attacker can decrypt authentication cookies.
- Even worse than that, he can **generate authentication cookies** with the name of any user. Thus, he can appear as anyone on the site. The application is unable to differentiate between you or the hacker who generated an authentication cookie with your name for himself.
- It also lets him to decrypt (and also generate) **session cookies**, although this is not as dangerous as the previous one.
- Not so serious: He can decrypt the encrypted ViewState of pages. (If you use ViewState to store confidental data, you shouldn&#39;t do this anyways!)
- **Quite unexpected**: With the knowledge of the machine key, the attacker **can download** any arbitrary file from your web application, even those that normally can&#39;t be downloaded! (Including **Web.Config**, etc.)

Here is a bunch of good practices I got that **don&#39;t** solve the issue but help improve the general security of a web application.

- [You can encrypt sensitive data with Protected Configuration][4]
- [Use HTTP Only cookies][5]
- Prevent DoS attacks

Now, let&#39;s focus on this issue.

- [Scott Guthrie published an entry about it on his blog][6]
- [ScottGu&#39;s FAQ blog post about the vulnerability][7]
- [ScottGu&#39;s update on the vulnerability][8]
- [Microsoft has a security advisory about it][9]
- [Understanding the vulnerability][10]
- [Additional information about the vulnerability][11]

The solution

- Enable customErrors and make a single error page to which **all errors** are redirected. Yes, **even 404s**. (ScottGu said that differentiating between 404s and 500s are essential for this attack.) Also, into your `Application_Error` or `Error.aspx` put some code that makes a random delay. (Generate a random number, and use Thread.Sleep to sleep for that long.) This will make it impossible for the attacker to decide what exactly happened on your server.
- Some people recommended switching back to 3DES. In theory, if you don&#39;t use AES, you don&#39;t encounter the security weakness in the AES implementation. As it turns out, this is **not recommended at all**.

Some other thoughts

- Seems that [not][12] [everyone][13] thinks the workaround is good enough.

Thanks to everyone who answered my question. I learned a lot about not only this issue, but web security in general. I marked @Mikael&#39;s answer as accepted, but the other answers are also very useful.


  [1]: http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310
  [2]: https://stackoverflow.com/questions/3720720/how-serious-is-this-new-asp-net-security-vulnerability-and-how-can-i-workaround-i/3721473#3721473
  [3]: http://www.youtube.com/watch?v=yghiC_U2RaM
  [4]: http://msdn.microsoft.com/en-us/library/zhhddkxy%28VS.80%29.aspx
  [5]: http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html
  [6]: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
  [7]: http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx
  [8]: http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx
  [9]: http://www.microsoft.com/technet/security/advisory/2416728.mspx
  [10]: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx
  [11]: http://blogs.technet.com/b/srd/archive/2010/09/20/additional-information-about-the-asp-net-vulnerability.aspx
  [12]: http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html
  [13]: http://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx

All Padding Oracle-Attack Solutions on Gang of Coders

Total of 1 Padding Oracle-Attack Solutions

How serious is this new ASP.NET security vulnerability and how can I workaround it?