On Tue, Sep 14, 2010 at 10:26 AM, silky <[email protected]> wrote:
[...] >> The cookie might have the hashed result of an SSN. Shouldn't, but might. > > I don't think it's hashing that is at risk (they mention AES). I think > the attack is that you can prepare an invalid encrypted message, and > brute-force-ish ask ASP.NET to decrypt it, and based on it's answers > you can get closer to getting the key that the other .NET process is > using. So, assuming this is so, you should never report a > cryptographic failure (though, it's still implied, because you don't > get what you want, so ...). But then again, I know nothing of the > attack and I'm not an expert, this is just my guess. > > The moral is probably to not forget that bruteforce-style attacks are > still legitimate. Details: http://www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/ (different tool but probably similar approach). >From there it seems that we can conclude what we thought initially: do not send back .net exceptions for cryptography errors (always something generic like "invalid username/password combination"). Also, a general throttling/blocking of repeated invalid attemps (perhaps somewhat-exponentially slowed as n increases) is appropriate (there are other risks associated with doing this; i.e. inconvenience for users via a DoS style attack on accounts, but you can at least consider it and other similar approaches). -- silky http://dnoondt.wordpress.com/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."
