Will hashing passwords in my use case improve security and why?

Question

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.

The 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:

1. The session host connects to the central server over TLS, sending a hash of its chosen password.

2. The central server replies with a generated session key identifying the session host.

3. The session client connects to the central server specifying the session key and the hash of the attempted password.

4. 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.

Thanks

Answer 1

As you have said yourself, the hash becomes the password in this case. Therefore it's no more or less secure. And you again correctly identified that the only real benefit is that the user cannot expose their password in the case of re-use. Personally I'd be tempted to generate passwords for the host, and then give them the details to send the client.

But really, it only matters if your users are putting their actual, used-other-places passwords into the password box. So the best solution if you don't like the one above might be to word it a bit differently so they instead stick a phrase or whatever in there instead of a password.

Answer 2

In your scenario the hashes add little security because the client sends the hash to the central server, however the client should send the attempted password, the central server then checks the hash of the password against the submitted hash.

Hashing is very important in this scenario, because you may have a malicious user. The malicious user has a real account and password, she then connects to the host server via the central server as normal. She is then connected to the host server and if she can exploit a vulnerability in this server she can dump the plaintext passwords of all other users. Salting should be handled as normal, i.e. the host sends the central server a hash and a salt, and the client sends a plaintext password over TLS, and the server verifies that the password and salt match.

Answer 3

I know this is an old question, but I thought I'd weigh in.

Normally the client sends 'X' (plain text password), which is converted by the server to 'Y' (hash) and stored. The benefit is that the thing that is known to and transmitted by the client is not the same thing that gets stored in the server's database.

What I think you're proposing is for the client to take 'Y' and send it to the server, where it is stored as 'Y'. So you're essentially storing passwords as plain text, even though that plain text happens to be a hash. That's not best practice, although I don't think it's necessarily bad in this case, since the user's original password won't be exposed in the case of a database leak. That said, I don't see any good aspects of this approach, since the TSL connection already encrypts the plaintext password while it travels through the wire. I think the server should always do some salting and hashing itself, even if the client does some hashing too.