Secure preshared key 2 way authentication

Question

I have the following setup:
A server and a client will be connected over tcp. The server and client both have access to the preshared secret key. When the client connects to the server, the client and server both need to know the key, so they need to use the same key to authenticate or it will fail.

I came up with the following process and would like to know if there is anything obviously wrong with it that I didn't see. The actual encryption is not relevant in this case. So this is what happens when the client connects:

1. Server generates a 16 byte salt (salt1).
2. Server calculates hashServer1 = HASH(key + HASH(key + salt1)).
3. Server sends salt1 to client.
4. Clients calculates using the received salt1 hashClient1 = HASH(key + HASH(key + salt1)).
5. Client generates 16 byte salt (salt2).
6. Client calculates hashClient2 = HASH(key + HASH(key + salt2)).
7. Client sends (hashClient1 + salt2) to server.
8. Server checks if received hashClient1 == hashServer1 and if not breaks.
9. Server calculates using received salt2 hashServer2 = HASH(key + HASH(key + salt2)).
10. Server sends hashServer2 to client.
11. Client checks if received hashServer2 == hashClient2 and if not breaks.

If I am not mistaken, this should be pretty secure when using a strong hash algorithm. The key is never send as clear text and due to the salt the data is different every time.

EDIT: Changed the salt used for hashing from saltX to HASH(key + saltX).

Answer 1

Don’t roll your own crypto. Use TLS-PSK.

https://en.m.wikipedia.org/wiki/TLS-PSK

Answer 2

The only glaring problem I see here is that the salt is effectively useless. The point of a salt is to make cracking more difficult by adding an extra unknown factor to support the entropy of the hashing process. Salts do not necessarily need to be secrets, but we do want them to have a few properties when it comes to securing hashes:

• never reuse salts
• dont give salts out for free
• dont use short salts

giving the salt each transaction will allow me to watch for patterns in their creation. of course, this depends on how true to random their generation is.

In this case if I'm an attacker sniffing this traffic, I have the salt every time. meaning I have effectively reduced the problem to cracking the PSK in every single case, and you provide two hashes and salts to me every connection, further increasing my pool.

This is still a big problem, I still have to see if I can find the value that leads to the hash you give, but in this case, once I have one hash+salt pair, I'm just cracking the PSK at that point.

I think the most important things here are that salts are usually used to protect large databases of information from reverse lookups or rainbow tables. But in your case, your entire server is subject to one password. Knowing the salt is a bigger deal here, and I would wager that makes the salt a secret even. Something worth guarding. Since if I really wanted to get in, I'd take one salt/hash pair and generate hashes until I found the PSK.

Answer 3

This protocol is called Challenge Response Authentication, and you could simplify your process:

1. Server sends the string timestampFromServer:HASH(PSK + timestampFromServer).

2. Client validates the hash, trusts the server and sends the string timestampFromClient:HASH(PSK + timestampFromClient)

3. Server validates the hash and trusts the client.

On 2, client only proceeds if the hash is valid, and that proves the server knows the key. On 3 the reverse is tested, and server knows the client also knows the key.

On 1, the server can even send timestampFromServer:HASH(PSK + timestampFromServer):TransientSessionKey. The client can now use the TransientSessionKey and the PSK to derive a symmetric key and use it on every communication with the server.

This way you don't need a salt storage, you don't need to worry about reusing salts (depending on the timestamp precision), and use less salts. You can authenticate both the client and server with less round trips too, decreasing latency, and if you use the TransientSessionKey you reduce the probability of leaking the PSK.