I am developing an application the architecture of which is arranged as follows:
Session host <---> Central relay server <---> Session client
All communication between the initiating
session host and the subsequently connecting
session client is relayed through the central server.
session host is to be secured such that it cannot be accessed without a public session key identifying it and a private password it has stipulated in advance.
In fact no communication what so ever should be possible with the
session host unless the
session client can prove to the central server it is authorized, that is to say that authentication should take place on the central server itself.
So in the workflow I have in mind:
session hostconnects to the central server over TLS, sending a hash of its chosen password.
The central server replies with a generated session key identifying the session host.
session clientconnects to the central server specifying the session key and the hash of the attempted password.
The central server checks the hashes for a match, if there is a match, the
session clients messages are allowed to pass through to the
session host, if there is not a match, authentication has failed.
Thus my question is as follows.
Does hashing the password in this way deliver any additional security as opposed to just sending the stipulated and attempted passwords? How should I handle salting?
I'm inclined to think that it's worthwhile as it means the full password is never sent across the wire even if over TLS. It is not even stored into RAM on the central server. It protects the users password, but offers no additional security for the session as the hash becomes the password.