0
\$\begingroup\$

I am using a server model similar to Steam or Minecraft:

  • There are community servers run by players and a hub authentication server that I control.

  • The client player logs into the game and receives a session token.

  • When the player wants to connect to a server, they request from the authentication server to exchange their session token for a server session token.

  • They then pass that server session token to the server which then checks with the authentication server if the token is valid, and if it is, the community server lets the client in.

My issue is, this gives the UGC server a lot of power. I know that if the UGC server is fully moddable, you can't stop a lot of stuff, but the main issue is that if a malicious admin intercepts this server session token packet from the client, the admin can use this to connect to an entirely new server pretending to be the client.

I need a solution to fix this and make a model similar to Steam or Minecraft's models. thank you.

\$\endgroup\$
3
  • \$\begingroup\$ I've found this.. reddit.com/r/gamedev/comments/8owlpr/… But im having trouble understanding it \$\endgroup\$ Dec 14, 2021 at 17:11
  • \$\begingroup\$ Wouldn't the server session token consist of some kind of one-way hash / encrypted signature of the destination server with the user's credentials, rather than just raw unprotected credentials that can be used with any server? The authentication server (possessing the secret key that generated this token) can then verify "yes, that is a valid token granting user X access to server Y" - which server Z can trivially conclude is not a valid request for itself and must be a replay attack / forgery. \$\endgroup\$
    – DMGregory
    Dec 14, 2021 at 17:20
  • \$\begingroup\$ Do you know if i can find some kind of example of this protocol? \$\endgroup\$ Dec 14, 2021 at 17:22

1 Answer 1

1
\$\begingroup\$

Instead of jury-rigging your own solution, you should look at existing open-source solutions to this very problem. Like OpenID, for example.

OpenID works basically like this:

  1. The client connects to the server, telling it its username.
  2. The server connects the authentication provider, asking it to verify a login attempt for a specific username. This login attempt also gets an unique login id, which it tells both the client and the authentication provider.
  3. The client connects to the authentication provider and tells it "I would like to perform the authentication for [login id]. Here are my credentials".
  4. The authentication provider confirms that the credentials check out, and when that's the case responds to the server that the login with this id was successful.
  5. The server lets the client into the game.

(Needless to say that all of this should happen through encrypted channels.)

Impersonation is impossible in this case because the login process requires direct communication between server and authentication provider. And because each login attempt gets an own unique ID, there is no opportunity for replay attacks.

If you would like to use this process, then please remember: DO NOT INVENT YOUR OWN CRYPTO! Anyone can come up with a security scheme they can't crack themselves. If possible, rely on a tried and tested open-source implementation.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .