I have a server and a client that need to authenticate to that server. The idea is that we have user/pass and the authentication generates a token that can later be used.

An important factor here is that I want to reduce the number of network round trips as much as possible. I came up with the following scheme:

  • Client generates a single use public key / private key

  • Client sends the server the following:

    • user
    • public key
    • hash(public key + pass)
  • The server load the relevant user and computes hash(public key + pass)

  • It then generates a token that the client will use, and encrypt that token using the public key.
  • Client decrypt the token using the private key, and can then use it.

The issue of token security is not relevant here. It is expected that most users will use this over HTTPS, but we need to avoid sending the password on the clear for cases where users use HTTP internally inside the organization.

As I figure, we prevent replay attacks using this approach because only the client can decrypt the token.

I'm aware that if an attacker can listen to the network they can just sniff the token on the next request after authentication, but that isn't the concern here.

Are there any holes that I'm missing?

  • $\begingroup$ So can I read from this, that 1.5 round-trips (client->server, server->client, client->server) are actually OK as well? $\endgroup$
    – SEJPM
    Mar 22, 2017 at 23:42
  • $\begingroup$ The transport is actually HTTP/S so that would be two. I'm not counting the token usage in the number of round trips. $\endgroup$ Mar 23, 2017 at 9:28

1 Answer 1


public-key, H(public-key||pass) seems open to offline password guessing. Other than that seems to achieve what you want under the adversarial assumptions.

  • 1
    $\begingroup$ Since the client need to send something to the server to prove that it knows the pass, it doesn't seem to me that there is a way to avoid it, is there? $\endgroup$ Mar 22, 2017 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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