2

I'm working on a simple multiplayer game to break the ice with network programming. I have a system where if the player moves, the server receives a move packet that contains some stuff like the timestamp the packet was sent, the keys they press encoded into a byte, the players unique ID, and their position.

What if the player can somehow send a packet pretending their ID is X where X is some random player or moderators ID? Am I approaching this packet wrong, should I encrypt the packets? Or is there a method commonly used in game network protocols to ensure that packets are who they claim to be?

Jon Blow
  • 23
  • 3

1 Answers1

6

Have you heard about JWT or stateless sessions?

This sounds like a job for an encrypted packet that gets sent to the client, and sent back, for the next packet to be sent. This JSON Web Token could be used to signify who talks to your server by containing the information it needs in an encrypted format to make sure things are secure and compliant. This is best done over an encrypted connection.

An example

Andy and Deli are playing a game. Andy gets a JWT with his information, and Deli gets a JWT with his information.

Some of the information in the JWT is the same(game id, game meta data, so forth) and some of it is unique(player unique id, player ip, something else unique to the player).

When Andy communicates, he JWT is sent along with his packets, and verifies his unique information. Once that is verified his move is then done, and forwarded. It then gets some ALTERED unique information(like updating the time of last move by this player) and gets sent back to him, and the move gets sent to everyone else.

Now Deli wants to cheat. He instead puts Andy's Unique id into his move and sends it to make it look like Andy did a new move into a bad place.

The JWT is decoded, and it's seen that Deli is cheating, so Deli gets kicked, and Andy wins by default since Deli sent a command for a user that isn't Deli.

A Rose by any other name

Often you'll see these also referred to as Cookie Sessions, Stateless Sessions, JSON Web Tokens, and a myriad of other names, but they all have the same idea(and when sent over TCP, usually are in the cookies)

What is a Stateless Session?

A stateless session is a session that lives and dies with it's token.
Usually they are encrypted on the server end with a server secret that is related to whatever is happening. These tokens don't live in databases, don't reflect any sort of long term storage, and expire eventually.

To keep them secure they are usually encrypted with a strong cipher suite, and a secret of some sort that gets decrypted on the fly, modified, and then re-encrypted. This information is usually a JSON document containing meta information that doesn't get modified often(if at all) that can be sent back and forth and since it's encrypted it means that any modification makes it null and void.

Any modifications to these render them as new sessions, and any data in them is lost. This means that if you do your checks and balances correctly you can even use it as a full session for a user on most websites.

Community
  • 1
Robert Mennell
  • 6,968
  • 1
  • 13
  • 38