Instead of passing an authentication token or api key in an http header to a server in the plain text, what if I calculated its hash and passed the hash? This way even if a adversary intercepts the hash, it'll be useless for them. And a server can easily calculate a hash of the real password on its side as well and then check if they match. A salt can be added also.

Will it work? Is this approach widely used?


No, this approach is not widely used and here's why:

  1. If the client hashes the password and sends this to the server, then doesn't that hash become "the password"? As an attacker, can't I just intercept the hash and use that in a replay attack?

  2. You said "A salt can be added also". This one actually is done in some protocols, when you add in a random value to make the hash different each time, it's called a nonce.

  3. Most importantly, the server knows the plaintext password!? Bad Idea! If your server knows the plaintext password, that means it is storing the plains in a database, that means a database breach leaks all your users' plaintext password. Only storing password hashes in the db protects you against this. Are you really willing to risk a total and complete breach in order to make your protocol a little bit simpler?

Bottom line: I'm happy that you're thinking about protocol design from a security perspective. I would encourage you to have a look at the TLS handshake because it is a very well thought-out protocol that uses a lot of the concepts that you're thinking about.

  • 1) Yes.... but at least, it won't appear in the plain text anywhere such as in logs. – アレックス Apr 9 '16 at 2:40
  • And why not use this technique while hashing is additionally applied on the server? It doesn't need to store the hash sent from the client as is. – forest Apr 9 '16 at 3:46
  • @forest That is true, but if your login page is HTTPS then it's not clear what you're gaining from that. If you mistrust the server that badly, maybe you shouldn't be using the service. That said, I have seen javascript pages that do a couple iterations of hashing the password client-side just so the server never even sees the plaintext password at all. But you risk annoying some of your userbase because javascript crypto can be wickedly slow on old phones, esp non-smartphones. – Mike Ounsworth Apr 9 '16 at 4:03

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.