bugtraq - Re: New Whitepaper: Anti Brute Force Resource Metering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050323150501.GJ13807@wsr.ac.at>
Date: Wed, 23 Mar 2005 16:05:01 +0100
From: "Peter J. Holzer" <hjp@....ac.at>
To: bugtraq@...urityfocus.com
Subject: Re: New Whitepaper: Anti Brute Force Resource Metering

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@....ac.at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae@....se

Content of type "application/pgp-signature" skipped