Wow, yeah, that's pretty bad. I wonder if it's deliberate, or if they simply don't understand the attack...

The funny thing about all this is that the fix is relatively easy: encrypt-then-sign, and validate-then-decrypt. From what I gather, ASP.NET doesn't sign their data (or they decrypt (and fail early) and then validate). Implementing this may or may not break some internal code due to more data, however, so who knows when they'll push a fix.

Though, please, correct me if I'm missing something. IANA crypto expert by any means, but this attack seems conceptually simple enough that most anyone should be able to understand the causes of it if they get away from all the misinformation around it.

edit: clarification: on the validate-then-decrypt, you should be almost entirely safe, as it's bounded by the security of your signature. To make it safer yet, return the same error on a padding failure after validation as on a validation failure, and always do all steps to guard against timing attacks. Otherwise, if they get lucky enough to make a valid data block that passes your signature, they can still see / time padding errors. But that should be astronomically rare, unless you're using MD5.

You make a good point. I wonder if the time frame between writing the encrypted data, and reading it back has anything to do with it. Because if it were possible for the time frame to be long, then the application would be required to persist the signature for a while.

You lost me a bit there... writing and reading it back, and persisting the signature?

To try to cover the base I think I see: ASP.NET uses a single encryption key for all sessions, until you change the values in the web.config file (which I think requires a reboot).

I was thinking that the signature needed to be kept on the server, away from the attacker, because they could simply re-sign the message, but now I realize that checking the signature first would prevent the routine from ever getting to the decrypt algorithm, and thus no information would be leaked, so the attack would fail.

Unfortunately Microsoft is a bit between a rock and a hard place at the moment; give too little info and they'll suffer once exploits start actually occurring, give too much and create some serious panic. Then again, there's a lot of implicit info in Scott Guthrie's post, such as the increased vulnerability of pre .NET3.5 SP1 app. Some more thoughts here: http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-pad...

His workaround results in an information-free error message with a cryptographically random delay...that's not enough?

No.

Cryptographically-random data + non-cryptographically-random data = non-cryptographically-random data.

In this case, the non-random data is (at the very least) where the checking code fails.

Good enough for an ASP site hosting a personal blog? Probably. Good enough for any moderate-scale target? No. Botnets break random delays pretty quickly, especially because a big attack means the server slows all operations, showing bigger and bigger differences between the two failure points.

I'd also be willing to bet that, even with custom errors turned on, at least slightly different code routes are followed between different error codes, magnifying the difference between the different errors despite displaying identically.

What I'd be interested in, if anyone knows, is if ASP.NET signs anything which is also encrypted. From what I've been reading / seeing, it seems it doesn't, and it's not just a checking-padding-first mistake. If that's the case, then ASP literally can't tell if something is valid until it hits code that tries to use it, which is a crypto-cracker's dream come true.