Login protocol

Question

How should i design a login protocol to be more secure the way i have it right now is

1. the client connects and sends his username
   
2. the server sends the salt(always same) for the user
   
3. the client adds the salt to the password hashes it and sends it to the server
   

This way the password is hidden all the time but it does not stop a hacker to just copy the hash if he can come over it and send it after he recived the password...

Answer 1

Leave security to a higher level protocol (SSH, SSL) and keep yours simple.

Answer 2

If the server only accepts the salted password on a connection which originally challenged with that salt then the hacker would have to keep connecting until he got the same salt as the one he saw the hash for. I'm not saying this is ideal (and a Diffie-Hellman key exchange followed by fully-encrypted authentication may be more secure, although still susceptible to a man-in-the-middle attack unless you're careful) but I think that simple tweak would at least be beneficial.

Then again, I'm not a security expert and you arguably shouldn't take security advice from any non-experts.

Answer 3

Security is hard.

Don't roll your own login protocol, either use an existing proven one or do something trivial and robust over an encrypted (SSH, SSL...) connection. There are so many robust drop-in implementations of proven protocols out there, and so many examples of systems failing due to flawed reinvention of wheels - if the login is protecting anything of any importance at all, there is simply no excuse.

That said, if your purpose here is to learn to design such algorithms, I strongly recommend Bruce Schneier's "Applied Cryptography".

Answer 4

Step 2 seems to be the bigger weakness, there. If you can make sure that the server sends a "sufficiently large" salt and NEVER the same salt, twice (I suspect a small portion of decent random numbers, plus an incrementing counter, then hashed MAY be enough, but I cannot prove that it is), that'd probably be enough. Alternatively, follow ssg's lead and encapsulate the whole thing in an SSL session.