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
