Hi,

For a while i started with network programming. So far i created networking part for my game and a simple game server. To play the game, players have to log in with their username and password. So far, the login procedure is simple, player sends their user name and password as simple strings. Passwords on the server are also stored as simple text files. When player attempts to log in, server reads the password from file and compares it with the received password.

At this point we really can't talk about security, so here is what i wanted to ask. I have read that passwords are usually stored in a salted hash form. The salt is also stored. When the server receives password from player it tries to hash it again and then compares it with stored hash.

Now to the question: How do i send the password over the LAN / internet? Sending plain text isn't secure. What are the usual methods to send passwords? What are the usual methods to log in to games that require user name, password?

If you can use HTTPS via an established library - go for it (with certificate checks and pinning).

Otherwise you can use e.g. OpenSSL to setup a TLS secured connection but there are plenty of things you can do wrong (e.g. not checking certificate validity).

Which language & libraries are you using for your project?

Sorry i forgot to mention, i'm using C++ with RakNet library.

I have read that passwords are usually stored in a salted hash form. The salt is also stored. When the server receives password from player it tries to hash it again and then compares it with stored hash. ... How do i send the password over the LAN / internet? Sending plain text isn't secure. What are the usual methods to send passwords? What are the usual methods to log in to games that require user name, password?

Yes about the salted hash. Never store the actual passwords, store a one-way hash of the password plus a salt. If you stored the password directly it would allow someone who steals the password file to have everyone's password, which is bad for hopefully obvious reasons. If you only stored the hash it may be possible for an attacker with the file to do some dictionary attacks and find passwords; adding a generated salt value unique to the account means even accounts with duplicate passwords will have different hashes, so extensive work is required for every password.

Security over a LAN is different than security over the public Internet. Between machines you can use a machine-level authentication such as Kerberos, which is the fundamental protocol behind Windows network authentication and domain security, as well as most unix-to-unix machine security.

Across the public Internet (or as an added layer within your network) it is typical to establish a secure connection with TLS, get the username and password (stored as a salted hash) over the secure connection, and then shift to a session key. The session key can then be stored in something the user doesn't normally care about, such as a request header or a cookie. The server can do various tasks like invalidating a session key periodically, sending a new session key invisibly to the user, such as modifying the value stored in a cookie. If the key or the cookie expires and the user isn't active at the time, they must log in again. TLS provides protection against replay attacks, so an attacker cannot mindlessly replay a logon attempt they didn't participate in. (They can still connect on their own and record their own credentials, or run a MitM attack and record the credentials.)

Session keys are sometimes tied to specific IP addresses as another protection, allowing the server to potentially detect issues like stolen session keys or replay attacks.

I wrote an article for the Game Programming Gems book series about this. I based that article on a previous web post about it:
http://www.mindcontrol.org/~hplus/authentication.html

That page is still OK, but should probably be updated to say "you really shouldn't use challenge/response if you can avoid it because it requires storing plain text passwords securely, which is a really hard problem."
It should also be updated to say "use scrypt() as your password hash function, with a generation count that is 'current year minus 2005' or better" and if you can't use scrypt(), at least use bcrypt().

Thanks for the link this is a good read and gives some really good insight into authentication and session management.