6

I just finally got into Keybase and was surprised to see this in the sign-up page:

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

  • 1
    What exactly don't you trust about the client? If the client is compromised, it will leak the password whether hashed locally or not. – David Houde Oct 1 '14 at 20:29
6

The whole point of Keybase is that the user doesn’t and shouldn’t have to trust the server with anything. All proofs can be verified without the server. As the Keybase passphrase serves to decrypt the private key used to sign the proofs, the server can’t be allowed to touch it.

Also, one has to trust the client to provide a registration passphrase, so even on websites less peculiar than Keybase, allowing the JavaScript to do its own password hashing there would be perfectly fine. (Allowing a user to log in with the same one, though, would be a very bad idea, as someone could just pass the hash.) They don’t, though, because those sites need to be trusted with the user’s password anyways (see parenthetical), and JavaScript hashing is both slower and not always available.

3

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

You got things mixed up here. There is a difference between trusting a client and hashing the user's password client-side.

You are right that we never trust the client. But here we are the client and have a need of hashing something. Why should we, the client, trust the server with our password?

So what happens is that you hash it locally so that the server will never know what you typed, and then send it. Then the server should make sure it's a valid hash instead of blindly accepting whatever it receives since, indeed, you should never trust clients.

Not sure how to explain this properly, hope it helps!

2

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

That is true, but not applicable in this case. First of all, the client messing up the hashing only hurts them in this scenario!

Traditionally, here's what bad things happen with a client-side hash:

  1. Someone types in their password (horsebatterystaple01)
  2. It is hashed and the output is 123456 (pretend that is a valid hash output)
  3. The server sees if the hash of 123456 matches the database. It then either grants or denies access.
  4. A hacker finds the password database on the server
  5. They send 123456 to the server and are logged in, skipping the hash.

Now, this is why it's easy for a hacker to hack a client side hash. The goal of a hash is to prevent the password from being recoverable, even if the password database is compromised. If they weren't hashed and salted properly, then the hacker could not only use that password to log into the site that was compromised, they could try other bank/email sites to see if the password is accepted.

Although client side hashing prevents the second scenario, it would still be easy for an attacker to just send the server 123456 and the server would grant access.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.