Bugtraq mailing list archives

Re: New Whitepaper: Anti Brute Force Resource Metering


From: "Peter J. Holzer" <hjp () wsr ac at>
Date: Wed, 23 Mar 2005 16:05:01 +0100

On 2005-03-21 18:53:42 -0000, Gunter Ollmann (NGS) wrote:
The paper is now available from the NGS website:
http://www.ngssoftware.com/papers/NISR-AntiBruteForceResourceMetering.pdf
[...]
"Web-based applications authentication processes are frequently vulnerable
to automated brute force guessing attacks.  Whilst commonly proposed
solutions make use of escalating time delays and minimum lockout threshold
strategies, these tend to prove ineffectual in real attacks and may actually
promote additional attack vectors.           

Resource metering through client-side computationally intensive "electronic
payments" can provide an alternative strategy in defending against brute
force guessing attacks.  This whitepaper discusses how such a solution works
and the security advantages it can bring."

Interesting paper. For web applications this actually seems to be
feasible. Which brings me to my first quibble: You claim that hashcash
"has already proven to positively reduce the success" of spammers. Is
there any example of hashcash being deployed in e-mail systems? I don't
know any and I can't even offhand think of any feasible method of how it
could be deployed.

The second point is that while you mention that "the client host will
dictate the speed [...] and consequently the electronic payment will be
less for new or high end computers", I think you underestimate the
effects. If for example the hash operation is implemented in Javascript
(which seems to be the most portable solution), you have to make the
computation easy enough that the user with the oldest hardware and the
slowest javascript implementation can still log in. An attacker would of
course use the fastest implementation available - he could even
reimplement the javascript code in hand-optimized C or assembler, if
there is only a small number of algorithms in use. I wouldn't be
surprised if that's 100 times faster on identical hardware. The speed
difference between the slowest and the fastest hardware is at least
another order of magnitude. So you should expect your typical attacker
to be able to compute hashes at least 1000 times faster than your
worst-equipped legitimate user.

        hp


-- 
   _  | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in
|_|_) | Sysadmin WSR     \the source, and you might run into a memory leak if 
| |   | hjp () wsr ac at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae () op5 se

Attachment: _bin
Description:


Current thread: