Use SSL/TLS to protect the password in transit. Public key encyption security is computationally infeasible to break - provided there are no implementation issues. Which is why you should use an existing implementation.

Note that you need a third party system to authenticate certificates to prevent man in the middle attacks.

Or you could implement (or use a pre-existing framework) Kerberos which is a secure authentication mechanism, irregardless of the level of encryption on the channel.

Quote:Original post by Antriel
Hi,
I have read some articles about this topic, most of them for php. What I need is a secure login procedure for client/server structure using tcp.
Everywhere I find this approach:
Having hash(pass+salt) saved in DB.
1. client send pass
2. server add salt and hash it, compare to DB stored hash
3. if they match - good, otherwise - bad

This method is obviously inadequate as it reveals the password to any twelve-year-old with Wireshark. Even sending a hashed password doesn't offer much security these days, since most hashing algorithms used for such purposes (notably MD5 and SHA1) are quite easily cracked on modern hardware. At least for short (<10 character) passwords. Besides, if someone sniffs the hash they can just modify their client to send the hashed password that they sniffed. So while the hashing may protect you against recovering the password (if you're lucky), you'll still not protect users from having their accounts accessed.

If you don't want to implement SSL or something similar, a simpler approach might be to do something like this:

1. Client connects.
2. Server sends a block of truly random data.
3. Client puts password + data block into a secure hash function, and sends it to the server.
4. The server repeats the same procedure, and compares the two hashes for a match.

The advantage is that even if an attacker were to sniff the hashed password, it's still useless because the random data block will change on every connection. That means that a hash is only useful once. However, it's still possible to crack the password by treating the challenge block as the salt.

Kerberos does require additional servers, which makes it a rather complex solution.

Public key authentication doesn't (the term I should have used is an "out of bound" authentication system - not "third party"). The client can't blindly trust public keys sent to it from the server - anyone can generate a public key. However, if you create a special certificate (a "certificate authority" cert) you can include it with the client program. Then, servers can generate their own certs, and get them signed by the certificate authority cert. Finally, the clients can try verify certificates they get with the certificate authority cert. If it isn't signed, you can give the client the option of continuing anyway. OpenSSL includes a suite of applications to create and sign certificates, and a library you can use for your program.

The main downside is the cost of authorising the certificates for the servers in the first place. It is still a pretty complex solution though.

Another alternative is a "trust on first use" system. This is similar to SSH. In this setup, we assume that the probability of a man in the middle is low on individual connections. If the client chooses to accept the certificate in the first use, it can cache the certificate. Each subsequent connection to the same server is as safe as the first one. If the initial connection is made on a network you trust (such as your home network) then the probability of a MITM should be extremely low.

Can you tell us more about your setup though?