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]

Date: Wed, 23 Mar 2005 10:23:34 +0000
From: Gunter Ollmann <gunter@...software.com>
To: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>,
	bugtraq@...urityfocus.com
Subject: Re: New Whitepaper: Anti Brute Force Resource Metering

Hi Amit Klein (+bugtraq)

> One thing that I think can perhaps be improved is the amount of 
> persistent data (the seed values) that the system keeps (in memory?).

Too true - but please bear in mind that the example used to implement 
resource metering was really just an example, and was based upon the 
anti-spam "hashcash" model.  This was purely done to keep things as 
simple as possible and for those familiar with that implementation to 
quickly see how it could be used in web-based auth.

The core of the paper revolves around the use of client-side 
computationally intensive routines that are designed explicitly to cause 
a delay in submission to the server.  The general criteria for a 
solution are:
a) It needs to be client-side.
b) It needs to be controllable - i.e. easy to increase/decrease the 
processing requirements.
c) It must be quickly verfiable by the server.
d) It should be appropriate for the application it is helping to protect.

Outside of that, it's fair game - the implementation fine points are 
down to the organisation that chooses to make use of an "electronic 
payment" resource metering solution.  ;-)

>
>It should be noted that with this modified scheme:
>a. A calculation done for one username+password pair is useless for 
>another pair (perhaps with the same username), because both the 
>username AND the password are part of the hashcash string.
>
I would not normally recommend the use of passwords in this manner.  
Basically, a password mapped to a user/customer should not really be 
stored anywhere at the server end - instead a hash of the password is 
stored (therefore, should anyone gain access to the database - they do 
not have the passwords).  In practical terms, this means that when a 
customer submits their auth details to the server, it calculates the 
hash of the submitted password and compares it to the hash it has stored 
in the backend database.

For your proposal, the server would need access to the real password to 
verify the hashcash.  Perhaps if the client-side sends a hashed value of 
their password instead?

Cheers,

Gunter