Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: New Whitepaper: Anti Brute Force Resource Metering

Subject: Re: New Whitepaper: Anti Brute Force Resource Metering
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: pgpjJJWTaTtva.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>