If the server is going to be freely available then obviously you need to decouple account logic from server logic, unless you want people to register a new account for every server they join. At that point, all the accounts need to be stored in a separate database, upon account creation you must:
- have the user generate a random, sufficiently long salt, say 16 bytes
- have the user hash his password using the salt (do not use MD5, SHA256, SHA512, .. use bcrypt, scrypt, or at the very least, PBKDF2, properly configured, this is CRITICAL)
- securely receive the salt, and the hash generated by the user (and his username, too..). This is far from trivial already, since you will need some sort of secure connection to the server, best is probably to do the registration online via an HTTPS form (SSL/TLS), of course if you want to avoid MITM you'll need to purchase an SSL certificate which is.. let's say it's not free, but you can do that later on. If you cannot securely transport the password to the server, you have zero security.
- perform a cheap final hash on the received hash, say SHA256, and store that along with the salt (CRITICAL)
Now upon login, you need a secure connection (if you don't, anyone can intercept the stuff you send and impersonate you via a replay attack), and then:
- client sends his username, and asks the server for his salt
- client receives salt, computes the same hash using the salt, and sends it off to the server
- server does the cheap hash on the received hash, and checks if it matches the hash in the database, if it doesn't, access denied
This is the basic password authentication protocol. A better approach is to use a protocol called SRP (no, that's not single responsibility principle, it stands for Secure Remote Password) which is considerably better than this, and, in fact, disallows brute force attacks assuming the server can authenticate itself (via an SSL certificate or whatever). Although it's more complicated, harder to deploy, and probably overkill.
All in all, you should probably use an existing password storage solution. In fact, if you were storing more sensitive information than just game accounts, say, credit card stuff, you would need to be PCI-DSS certified, but there is no moral reason not to approach game account passwords with the same care. Many people wrongly use the same password everywhere, and you do not want to deal with the legal issues you may end up facing if your account database fails.
At this point, there are two points of attack:
- on the password database, this is not a problem if the client properly configured the hash
- during account creation, this doesn't work because all the server gets is a salt and the password hashed using this salt, so unless the password is extremely weak to begin with, he won't be able to brute-force it, especially if you use a slow hash as recommended
This will fulfill your original requirement of protecting against unscrupulous server owners, however you MUST be able to set up a secure channel between the server and the client when the hash is sent over the network, because otherwise, your password will be safe, but won't actually protect anything. Anyone can snoop on the hash, and then send it himself at a later time, and boom! he has access to the user's account.