Authentication server != game server

The authentication server should handle logging users in - checking the game version, making sure the user account is valid, the password is correct, and the player is allowed to access the game (Not banned, etc).
Once all that's passed, it should communicate with the game server privately, to tell it a key for this new user (Something like a hash of user name or user ID, current time, IP address and some salt value). The authentication server also tells the connecting player that key.
The player's client then disconnects from the authentication server and connects to the game server, handing in the key it got from the authentication server.
The game server checks the key and sees that it's valid so allows the player to join.

The game server should probably discard key that haven't been used in a minute or so, to remove old entries.
The advantage with this method is that the authentication server can also reply to the client with the IP address and port of the game server, which will let you do load distribution if you need to, and will allow you to change the IP of the game servers if you need to (You'll still need a fixed point to connect to (the authentication server)).

This is just one way to do it, there may be some vulnerabilities in it that I haven't noticed...

Only problem I see with that is how does the auth server know which game server the client is connecting to if there are multiple game servers?

Would it be feasible/safe to encrypt the ACCOUNT_ID and some misc data (account total active time, etc; for stuff like vetren rewards.) send that to the client (The client it self does not have the decrypt key) and it just relays that info to whatever server it is connecting to and that server looks up a character list using the ACCOUNT_ID?

Quote:

Original post by riddlemd Only problem I see with that is how does the auth server know which game server the client is connecting to if there are multiple game servers? Would it be feasible/safe to encrypt the ACCOUNT_ID and some misc data (account total active time, etc; for stuff like vetren rewards.) send that to the client (The client it self does not have the decrypt key) and it just relays that info to whatever server it is connecting to and that server looks up a character list using the ACCOUNT_ID?

The data you send to client is a token - for all practical purposes it's random sequence of garbage data.

When you create a token, you store it server-side, mapping the token to player.

The whole idea behind this is that you end up with one time pad. Since data only makes sense to the server, and token expires, there's no way to compromise this authentication scheme, short of compromising internal data store.

But the key security issue is, no matter how you generate the token, it must not be reversible by any means, which is easiest to achieve if it doesn't contain any information in the first place.

Quote:

Original post by riddlemd Only problem I see with that is how does the auth server know which game server the client is connecting to if there are multiple game servers?

The authentication server can decide, or it could be a bit more involved and give the client a list of game servers and ask it to choose one, then once one is chosen the IP is returned and that game server is notified.

Quote:

Original post by riddlemd Would it be feasible/safe to encrypt the ACCOUNT_ID and some misc data (account total active time, etc; for stuff like vetren rewards.) send that to the client (The client it self does not have the decrypt key) and it just relays that info to whatever server it is connecting to and that server looks up a character list using the ACCOUNT_ID?

I wouldn't do that, if the client can decrypt the data, then they can easily cheat or hijack another account.
What would be better, is for the authentication server to send that data to the game server when the client connects. The game server then just sees what account ID, etc is associated with the connection key the client uses.

A common backend system, such as an SQL Database would be helpfull to start with. I have implemented a similar setup before with some websites and this is the general idea:

Client connects to the authentication system and attempts to authenticate.

If authentication succeeds, the server generates a unique ID (should be unpredictable for security reasons) and inserts a record into a database with the user's name, the ID, and time of login.

User then passes to the destination server, and when sending any requests to the server includes the unique ID to act as the session ID. The destination can verify the user is authenticated by looking up the unique id generated at authentication.

This could further be improved, if speed is a concern, by maybe running a service on the destination system that would keep the session in memory. So instead of the authentication inserting to the database, it would send it to the destination service directly.

You would also have to invalidate session after a set period of inactivity.