[
Lists Home |
Date Index |
Thread Index
]
> No, I don't think that's true ...
> Packet snarfings are required for
> both attacks.
Right, my typo/goof.
> Once the packets are snarfed, a hole that does not require any
> decryption and give immediate, time limited access is worse than an
> attack that requires a decryption that may not succeed.
It all depends on the (hate to re-use the word, but..) context.
In many cases a limited-use crack is much less worrisome than the
possibility of an adversary getting the long-term key. It all
depends on what's being accessed: a stolen session to the WMD is
bad; a cracked copy of the password to my online bank account is
bad, too. You cannot make generalities, which is why I try to
be careful and use words like probably, and "in my opinion."
> A strong
> password is a pretty damn good defense against an offline, dictionary
> attack on digest authentication.
Users choose bad passwords. The security literature is rife with
papers about this. Several security protocols (SPEKE, IETF's Sacred,
etc) have been designed to address this. As John described Reuters,
they're better than almost everyone else, but if they let users
change their passwords, all bets are off. :)
> I don't see any equivalent action a
> client can take to protect themself against a cookie based attack.
Make sure they always connect to the site with SSL.
> *I* can protect *myself* against your prosed attack on disgest
> authentication.
Well, maybe. Let's work the numbers.
We can assume your password is something that can easily be typed on
both your keyboard and the server's keyboard, which limits it to
printable ASCII, or ('~' through ' ', inclusive). If their back-end
system is an IBM big iron machine, than you're limited to the ASCII/EBCDIC
subset which is like 64 characters. But let's pick eight printable ASCII
as a more reasonable key space. That's 95**8, or 6.6e15 possibilities.
My small workstation can do 266,000 64byte MD5 operations per second,
according to the openssl speed command. That's 2.3e9 per day, so it
will take me 2.8 million days. But for under a million I can buy
enough systems and partition the problem, so that I could do it in
under a day. Is it worth a million dollars to crack your password in
a day? Probably not. Is it worth it to be able to get lots of big bank
customer online passwords? yup.
Further, we could precompute and store the state. Right now you'd
need 6.6e15*128, or 850,000 terabytes. Microsoft Terraserver is 3TB,
as a point of reference, but you don't need a SQL database for this,
just flat files of numbers. Still, it's probably a little out of
reach for the next year or two. :)
If we limit your "strong" password to an alphabet of 64 characters,
by the way, the adversary's job gets a thousand times easier. My
million dollars can now crack 1,000 passwords a day.
> And excepting SSL, I don't think the defenses you propose are
> sufficiently effective, even if the server does implement them. :-(
I beg to differ. The limited-use-counter model is a particularly
strong defense.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
