From what I read until now...
The attack allows someone to decrypt sniffed cookies, which could contain valuable data such as bank balances
They need the encrypted cookie of a user that have been already logged in, on any account. They also need to find data in cookies - I hope that developers do not store critical data in cookies :). And there is a way that I have below to not let asp.net store data in the login cookie.
How can someone get the cookie of a user that is online if he doesn't get his hands on the browser data? Or sniff the IP packet ?
One way to prevent that is to not allow cookies to transport without ssl encryption.
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Also one more measure is to prevent storing Roles in cookies.
<roleManager enabled="true" cacheRolesInCookie="false">
Now about the cookies that are not secure for the regular pages, this needs some more thinking what you left your user do and what not, how you trust him, what extra check you can do (for example if you see a change on the ip, maybe stop trust him until relogin from security page).
Can some hacker steal the cookie from a user and login with that name on a web site?
How to check from where attacks come and not give back informations. I wrote here a simple way to prevent the padding is invalid and logging at the same time to track down attackers: CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed
The way to track the attacker is to check the padding is invalid. With a simple procedure you can track them down and block them - they need some thousands of call on your page to find the key !
I have download the tool that suppose that's find the KEY and decrypt the data, and as I say its trap on the above code that's check the viewstate. From my tests this tool have many more to fix, for example can not scan compressed view state as it is and its crash on my tests.
If some one try to use this tool or this method the above code can track them down and you can block them out of your page with simple code like this one "Prevent Denial Of Service (DOS)", or like this code for preventing Denial of service.
Its seems from what I read until now that the only think that is really need it to not give information back about the error, and just place a custom error page and if you like you can just create and a random delay to this page.
a very interesting video on this issue.
So all the above its more measure for more protections but not 100% necessaries for this particular issue. For example to use ssl cookie is solve the snif issue, the not cache the Roles in cookies it good to not send and get back big cookies, and to avoid some one that have all ready crack the code, to just place the admin role on the cookie of him.
The viewstate track its just one more measure to find attack.