[bullen]

Just hash = hash(secret + salt) and the server enforces the single use by generating and sending one for each authentication, so you need double handshake:

client ----- server

req salt -> gen salt

hash sec. <- reply salt

send hash -> remove salt

all good? <- verify hash

[jameshart]

How does the server verify that the salt it receives in the second request is the same salt it generated in the first response? Does the server have to retain state?

Also you should maybe read https://benlog.com/2008/06/19/dont-hash-secrets/

[bullen]

Servers are stateful.

[jessaustin]

Which hash are you using? All this would be for naught if it's one of the many susceptible to length extension attacks; e.g. SHA2. This is the reason everyone uses HMAC now.

[bullen]

The salt is not attacker-controlled.

[jessaustin]

I thought the left column above was the client/attacker? She doesn't actually have to use the salt you send her...

[EDIT:] Actually never mind. I'm sure this is all fine, and look how much more efficient this 3-way back-and-forth conversation is than any conventional auth scheme would be. You should design all your own auth.