On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:
Any implementation that returns distinguishable error conditions for invalid padding is vulnerable...
Oh come on. This is really just a sophisticated variant of the old "never say which was wrong" - login ID or password - attack. In this case it's padding or MACing. If either fails the result should be the same: something went wrong, sorry for you. The POET Oracle depends upon the server taking a shortcut and signaling which went wrong first.
I wouldn't call that a shortcut - one has to actually define two failure returns and choose which one to send. More code, more complexity. But ... there's a reason for doing this, in virtually all situations: Manageability, Without some detail as to exactly what went wrong, it's very hard to know what to correct or even where to look.

Cryptographic protocols are outliers here, because here you really can't afford to make the system "manageable" if the cost is that it can then serve as an oracle. This is one reason it's so hard for most developers to produce correct crypto implementations: So much of what is good practice almost everywhere else ends up being hazardous when it comes to cryptography.

It's not that there are *no* other situations where better error messages are a potential liability. The classic example is error messages that leak information about directory configurations or database tables, thus enabling other attacks. The difference is that such information, in most cases, is only problematic if the actual system *has some other vulnerability*. We may not be at all good at producing systems without such vulnerabilities, but at least we know in general principle how to do so. (If there are no SQL injection attacks, knowing what tables exist probably isn't useful to an attacker.) One might argue that a cryptosystem that is vulnerable to a "what failed" attack is also buggy - but we really have no general idea how to fix them. So we have to avoid them by accepting hard-to- manage protocols.

By the way, the "don't acknowledge whether it was the login ID or the password that was wrong" example is one of those things "everyone knows" - along with "change your password frequently" - that have long passed their "use by" date. Just what attack on a modern system does revealing that a guessed login ID is correct actually allow? It can only be used in on-line attacks, and it's been years since any decent system didn't protect against high rates of failures in on-line authentication. Besides, valid - or highly-probably-valid - login ID's are typically cheaply available for most systems anyway.

I'm really tired of using up my on-line password tries, only to discover that I accidentally erased the last character on the login name, or added a trailing \ when I went for the RETURN key! Systems are *so* nice to keep re-prompting with the bogus username.

Really, most systems these days reveal valid usernames quite easily. Both Windows boxes and Macs typically give you a pull-down list of accounts to log into. Web logins have ways to recover passwords for lost accounts that usually reveal if you get the account name wrong - and then give you a way to recover the account name. Can you think of an example in, say, the last 20 years of an attack that would not have been possible if the system had made it difficult to determine valid usernames?
                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to