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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With