Passwords are very sensitive information for our players, since even though they really shoudn't, they may be using them in other places. So if our database is compromised, we really want to avoid giving them up, to protect our players. The way we do this is create a one way hash of the password when the players account is created, then when the player logs in, we can hash the supplied password and see if it matches. This way we no longer need to store the actual password in our database.
But it is not enough to just hash the password, since computers are getting faster all the time and sometimes hashing alogarithims can have weaknesses discovered in them. This can lead to hackers being able to quickly discover what a password was even when it is hashed. Such as rainbow tables, and just building a big database of every hash they try.
One way to make the hash stronger, is to add what is called a salt. This is just a random string that is appended after the password before it is hashed. So even if the player chose a weak password like "cat", the hacker might already have a hash for it, but it's a lot less likely they have the hash for "cat+sdjldfjdlfowhfwehdwiluhwewe". We append the hash after, since hashing alogarithims work through the data sequentially a sneaky hacker could hash the salt once, and use that as the start point for every future attempt, which would reduce the usefulness of having a salt to begin with.
Another way to make password hashes more secure is to loop over the the password many times rehashing the result of the previous hash. This makes the hash take longer to create, which is not a big problem on login, and that makes it take longer for a hacker to try all the possibilites to reverse a password.
Also, in the future when computers improve, it's possible to increase the number of cycles without knowing the original password, we just continue to hash the existing hash.
Bringing it all together
So with all this functionality, how do we actually store the hash in the database? We could use multiple columns or fields, but it is nice to self contain everything in a single string:
MD5;5;salt123;hash123
Here you can see we are storing the hash alogarithim SHA256, the number of iterations 5, the salt salt123 and finally the hash itself hash123. Obviously these are slimmed down values, as an example, real values would have far more gibberish.
One other thing to think about is that you should also make sure that your connections to the server are encrypted as well, so nobody can snoop on the passwords as they go over the internet to your server. If you are using simple web requests, then HTTPS is all you need, for more interesting socket connections, check out SSL.