I was wondering recently how to create secure mechanism for sending password while log in to the system. Then i had wicked thought why to send password at all.

Let's imagine mechanism where client sends user id who wants to be logged in, server "welcomes with bread and salt" by sending challenge and random salt.

Client calculate hash of concatenated salt and password, and then uses it as shared secret to calculate HMAC of challenge, and sends it back to server.

In this case login details are never shared across the network, and login message cannot be replayed.

But are they any downside of this which i didn't thought about? And why it's bad idea (I'm assuming is bad, as nobody is doing in this way)

  • 1
    Use HTTPS. It works, you don't need to roll your own crypto, and it's future-proof. If you leave the code unattended for a decade, it will make sense later. Rolling your own scheme usually does not makes sense after a while.
    – ThoriumBR
    Jul 22, 2019 at 23:22
  • @ThoriumBR I'm not implementing this mechanism, i'm just looking at this as concept. Never claimed not to use https, just not sending password. I'm also not rolling my own crypto, just looking at alternative authentication mechanism which is using known and widely accepted cryptographic algorithms. Yes, lot of own schemes does not have sense, and i want to understand why this one doesn't.
    – user902383
    Jul 24, 2019 at 17:44

2 Answers 2


What you described is a good schema, already exists and it's called Challenge Response Authentication. It indeed prevents the password from being seem in the wire, and is currently used by NTLM, for example.

The problem is that you must create some way to authenticate the server first. Otherwise the client may talk to the attacker, the attacker talks to the server in his place, sends an specially crafted challenge to the client, and bruteforces the result. Client receives an authentication error, receives a legit challenge from the server, and the attacker hijacks the connection. Later the attacker can bruteforce the hash on the first iteration and get the password too.

TLS is the currently correct way to sending secrets. It authenticates the server, and optionally the client. Can use lots of algorithms for hashing, signing and encrypting, and can be transparently upgraded for using newer suites.

If your intention is studying, the above link about NTLM is a good read.


You should transfer the password over HTTPS. For storage, hash the password with Argon2.

Do not attempt to roll your own scheme. Anything beyond the above is generally unnecessary except for specific circumstances (e.g. where you need the server to have no knowledge of the password, in which case you want SRP).

  • 1
    This is not answer for my question. First I never said anything about not transferring data on secure channel, second my question is not about storing password. It's about idea of replacing traditional authentication mechanism with one based on zero-knowledge proof.
    – user902383
    Jul 24, 2019 at 17:38
  • 1
    @user902383 Sorry, it wasn't clear to me that you weren't just trying to design a pass-the-hash style authentication mechanism. SRP is a ZKPP solution and you should almost certainly use that if you require ZKP.
    – Polynomial
    Jul 24, 2019 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .