phc-discussions - Re: [PHC] Technical FAQ draft

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAGiyFdciGJTgxvF-TrVsdbE5DUNdfG_GHyh+6XKK1ha1kGzSCw@mail.gmail.com>
Date: Mon, 6 May 2013 11:41:32 +0200
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
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 <codesinchaos@...il.com> 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.