# Single roundtrip authentication

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?

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