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] [day] [month] [year] [list]

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

Hi Gunter+BugTraq

See my comment below.

Thanks,
-Amit

On 23 Mar 2005 at 10:23, Gunter Ollmann wrote:

> >
> >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?
> 

Exactly! Which is what I suggested in my email (the "modification to 
the modified method"). Here's the text from the bottom of my original 
email:

<FROM_ORIGINAL_EMAIL>

Regarding the fact that the password is used in the modified method: 
As I said above, this is both less elegant, and in some cases may be 
considered less secure (the original method was potentially unexposed 
to the password).
However, a simple modification to the modified method ;-) can take 
care of this shortcoming. Instead of providing the username and the 
password, it is enough to provide, say:

salt ^ ":" ^ HASH(username ^ ":" ^ password ^ ":" ^ salt)

the system can then send a pass/fail status to the "normal" 
username+password authentication system, along with the above value,  
which the authentication system can (and must) verify. That is, the 
system doesn't have to know the username and the password. It is 
enough for it to verify that the hashcash was calculated for the 
specific username and password that are provided.

While this indeed takes care of the username+password exposure in the 
system, it also necessiates a tighter integration with the standard 
authentication system (which now must verify the hash value).

</FROM_ORIGINAL_EMAIL>

Regards,
-Amit