

Client Side Cryptography - Should You Hash Passwords on the Client - rvtraveller
http://checkthelog.com/2013/05/client-side-cryptography-should-you-hash-passwords-on-the-client/

======
jstanley
Errr... you missed the main point!

If you hash passwords on the client, you aren't doing hashing right! If you
hash passwords on the client, all an attacker needs is a user's hash, and then
he can send it to you and get logged in _without ever knowing the user's
password_.

The point of doing hashing is that a compromised database doesn't allow the
attacker to login as arbitrary users. If you do the hashing on the client side
you completely obliterate that as there is no way for the server to know if
the hashing was _really_ done on the client side, or if a hash was blindly
replayed.

EDIT: Fortunately, you got the right answer (which is "no, you shouldn't hash
passwords on the client"), even if you're reasoning is... a little off :)

EDIT2: See <http://en.wikipedia.org/wiki/Digest_access_authentication> for a
way to do client-side hashing securely.

~~~
thirsteh
> If you hash passwords on the client, you aren't doing hashing right! If you
> hash passwords on the client, all an attacker needs is a user's hash, and
> then he can send it to you and get logged in without ever knowing the user's
> password.

It doesn't matter if the server gets a password or a digest, as long as it can
verify it. Hashing on the client side is obviously superior to hashing on the
server side, since the original password is never transmitted over the wire.
It is for the same reason protocols like SRP exist. (If you're worried about
somebody compromising your digest database and logging in with those digests,
you can just hash them with a cheap function like SHA-256 on the server side.
There is no reason for the server to use an expensive function since the
client has already stretched the input.)

Unfortunately, SRP doesn't do key stretching, so it is trivial to brute-force
the original input if you get a hold of the verifiers. But there'd be nothing
wrong with e.g. a client-side scrypt mechanism that uses TLS for the
transport, or even SRP/TLS-SRP (although you would need your server to
manage/sync the salt.) It just hasn't been feasible so far since no efficient
implementations have been available to web applications.

What you should take away from password hashing is that it exists primarily to
protect users from themselves. If everyone used unique passwords with 256 bits
of entropy for everything, we wouldn't need it. We need it because they use
weak passwords, and they use the same ones in many different places. If your
server gets owned, it likely doesn't matter whether they can log in with
contents of the database or not--they're already inside, and can probably
easily find another way. What matters is that by making it expensive to brute-
force the original input of possibly thousands of your users' passwords, you
make it very hard/cost-ineffective (if you do it properly) for an attacker to
compromise many/all of their other online accounts.

PS: Digest auth as it exists today is a joke. It uses no stretching
whatsoever, and is thus trivial to brute-force, whether by a MITM or an
attacker who has gained access to the server's digest database.

~~~
jstanley
> Hashing on the client side is obviously superior to hashing on the server
> side, since the original password is never transmitted over the wire.

Can you elaborate on this? All client-side hashing does is replace the user's
password with some hash, which now effectively becomes their password.

I don't see how this buys you any security. The user's password is irrelevant
if all the server ever sees is a hash of that password.

~~~
thirsteh
You're thinking about this the wrong way. It's not supposed to buy _you_
security. It's supposed to protect the user. (Yes, in the narrow case where an
attacker has access only to your accounts table, and you want to prevent them
from being able to log in as a user, hashing helps, but that can be separate
from the stretching--a normal hash function will do just fine to prevent
someone from simply presenting a digest to your login mechanism.)

As you just said, there is no difference between using a password or a hash
digest, since the server just needs to verify either of them. So, using a hash
digest from the client (generated by a strong password hash function) is
superior since an attacker, whether a MITM or somebody who has compromised
your servers, will have to spend a lot of time and money extracting the
original password if they get a hold of the digest. The reason we currently
generate these on the server side is not that it is more secure--in fact it is
terribly insecure if somebody compromises the communications channel or the
server itself, since they will be able to read the original, plain-text
password--but rather that it is cumbersome, for now, to do it on the client
side.

