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?
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.
I agree, unless this attack completely crashes the .Net stack to allow privilege escalation or similar, it's complete hyperbole.
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, 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.
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.