|
BugTraq
New Whitepaper: Anti Brute Force Resource Metering Mar 21 2005 06:53PM Gunter Ollmann (NGS) (gunter ngssoftware com) (2 replies) Re: New Whitepaper: Anti Brute Force Resource Metering Mar 22 2005 04:50PM Amit Klein (AKsecurity) (aksecurity hotpop com) (1 replies) Re: New Whitepaper: Anti Brute Force Resource Metering Mar 23 2005 10:23AM Gunter Ollmann (gunter ngssoftware com) (1 replies) Re: New Whitepaper: Anti Brute Force Resource Metering Mar 25 2005 10:10AM Amit Klein (AKsecurity) (aksecurity hotpop com) |
|
Privacy Statement |
> The paper is now available from the NGS website:
> http://www.ngssoftware.com/papers/NISR-AntiBruteForceResourceMetering.pd
f
[...]
> "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 (at) wsr.ac (dot) at [email concealed] \you enable embedded haskell as a loadable module and
__/ | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae (at) op5 (dot) se [email concealed]
[ reply ]