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

Message-ID: <CAK9dnSzRmLOQR_eCRiMWbjpEvYW=1e-_Cr=_+uGRbYrEndJhJA@mail.gmail.com>
Date: Mon, 6 May 2013 11:26:21 +0200
From: CodesInChaos <codesinchaos@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Technical FAQ draft

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

Content of type "text/html" skipped