Where do I salt and hash my Passwords? At the client or at the host?

I think it would be smarter to salt and hash passwords directly on the client's machine. The reason is, that I actually never want to get the password of the user. It is a string that should be secret to him, not to both of us. Now someone argued, that you want to keep the salt a secret, so you can not send it in clear text over the channel. Apparently, that is not the case. So now I don't see any reason, why I shouldn't just request a hash from the client side. What do you think?

edit to discuss the issue of sending a clients password to the host is actually not directly the issue. The issue for the client is to send the password out of his computer at all. An optimistic client may assume that his computer is save territory. But everything going out开发者_开发技巧 of that cable (or antenna) is Eve's territory. You can never be too paranoid in a security scenario. So again: The password should never leave the clients computer!

Sending either the passphrase or its hash lets an attacker record the hash and use it in a replay attack.

You generally want to use a challenge/response protocol, which means you send out a random number. The client encrypts (or does a keyed hash on) that random number using the hash of their passphrase as the key, and sends back the result. You do the same, and see of the two match.

This lets you verify matching keys without every sending the key itself across the insecure channel.

As for how you get the data initially to be able to do that comparison, yes, you usually want the client to hash the passphrase, then encrypt it with the server's public key, and send the result of that encryption.

The trouble with that is that the salted, hashed password then travels over the network, and if anyone intercepts it, they can use it.

What might work is if the server sends the salt to be used to the client, and the client then sends back the salted, hashed password using the server-created salt. The attacker might be able to capture the reply, but it won't help since the server's salt will be different each time, so the response from the client will be different each time. However, that requires the server to know the password so that it can rehash it with the salt, defeating one of your goals.

Fundamentally, the server has to end up knowing something to ensure that the client isn't spoofing it; and the classic way to do that is to have the server store the salted, hashed password and the client sends the password to the server, which validates what the client sends by salting and hashing the sent password and comparing the result with what it has stored. This avoids the server keeping the password in clear text, but does mean that the password travels over the wire. Make sure that the password is encrypted before being sent, therefore.

Generally, hashing is meant to obfuscate actual passwords and doesn't protect against replay attacks. You need a secure sockets layer for ensuring the channel is protected.

What hashing is good for is to protect against information leaks. For instance, say someone got hold of your users table and now they have a great deal of accounts. Since people reuse passwords, the accounts can be used to attack other sites. Hashing makes it difficult to reverse the hash into a password.

You want to hash a password at the client side only if you are going to store that password locally, such as a mobile device. Generally, you want to do the hashing at the server level.