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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 6 May 2013 11:41:32 +0200
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] Technical FAQ draft

Added the following:

A possible solution to this problem is that the server stores a "fast"
hash of the "slow" hash computed by the client.
However this approach seems difficult to implement because of the
diversity of client platforms (and thus the difference of performance of
the "slow" hash).

On Mon, May 6, 2013 at 11:26 AM, CodesInChaos <> wrote:
>>Why not hashing passwords on the client of a web service to eliminate
>>  the risk of DoS on the server?
>> If the server receives a hash rather than a password, a leak of the
>> hashes database allows to impersonate users without finding their
>> passwords (in the spirit of pass-the-hash attacks).
> While this isn't exactly incorrect, it's still misleading IMO. Running
> the expensive password hash on the client is great in principle.
> This attack can be easily prevented by running a cheap hash/HMAC
> on the server (using the salted password hash the client sent as input)
> or by using SRP.
> The real reason why we don't hash on the client is that it requires
> a fast password hash implementation on the client. This works well
> with normal applications, but not so great with web applications since
> it requires the user to enable javascript and needs good performance).
> But that well become less of an issue once we get crypto-apis built
> into the browser.

Powered by blists - more mailing lists