To decrypt it you need an exception message...so turn on custom errors and you're protected it seems. Assuming you don't do that, once you decrypt it you get what, a session ID? Then what?
All they need is distinguishable errors when decrypts fail. The contents of the error are irrelevant. You can send a bare 500 with no content and still be trivially vulnerable to this attack.
Besides what storm said: decrypting isn't the problem, being able to encrypt a new cookie is. If I can "bradhe" as my username in my own cookie, the default ASP.NET forms auth will consider me logged in as you.
Comments
To decrypt it you need an exception message...so turn on custom errors and you're protected it seems. Assuming you don't do that, once you decrypt it you get what, a session ID? Then what?
You apparently don't need the exception message at all. This was all discussed on the thread 3 days ago: http://news.ycombinator.com/item?id=1687547
All they need is distinguishable errors when decrypts fail. The contents of the error are irrelevant. You can send a bare 500 with no content and still be trivially vulnerable to this attack.
Fair enough, I guess I didn't understand the attack thoroughly.
Besides what storm said: decrypting isn't the problem, being able to encrypt a new cookie is. If I can "bradhe" as my username in my own cookie, the default ASP.NET forms auth will consider me logged in as you.