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:
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?
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.
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.
client ----- server
req salt -> gen salt
hash sec. <- reply salt
send hash -> remove salt
all good? <- verify hash