Q:

How to avoid password TCP message sniffing and subsequent hijacking

I'm developing a TCP Streaming API for "IoT" devices in LabView.
The TCP Server will be listening to a certain port, and our devices will try to connect to it. In order to know that the connecting client is from our company, all our servers and clients will share a private key and a password. When the client connects successfully to the socket, it will send the secret password cyphered in AES256 with the private key.
But what prevents an attacker from sniffing a client's credentials message and resend as it is to the server to gain access? Cyphering doesn't protect that.

A:

You could use a challenge-response mechanism. The server sends a random string, the client signs that using the private key. Since the server sends a new challenge every time, a replay attack won't work.
Or just use TLS to properly encrypt the connection. You could even use client certificates to replace your AES-encrypted secret password. TLS can provide both encryption and authentication, which seems to be what you are looking for. And another advantage is that you have to do a minimum amount of cryptography yourself, reducing the chance of implementation mistakes.

