0
\$\begingroup\$

I am new to networking. I am currently using C# TCP/UDP for my multiplayer Unity game. I send player movement by sending a packet with a header containing clientid assigned by the server to the client. The clientid is not like a password/session id but just a integer to identify packets send by different client. How do I prevent someone sending a fake packet that the clientid doesn't belongs to him.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

When the player joins the game, have the server generate a random token to send them as part of the "successfully joined" confirmation message.

The player can then send that token back with each update. The server then checks whether the token it received matches the one it assigned, and ignores it or logs an error if there's a mismatch.

Since no other player received player A's secret random token, none of them can successfully spoof a packet from player A without an astronomically lucky guess.

This works even in cleartext if your threat model is some other player/attacker not on player A's network, nor an insider/infiltrator with access to any of the intermediate servers/routers relaying the message, where they could sniff the token out of the reply to player A. To defend against that type of attacker, you can also encrypt the packets using TLS.

\$\endgroup\$
5
  • \$\begingroup\$ but will the packet be too large if they send a token each movement if the token is like 64bit? And encryption and decryption also cost a lot of performance. Would that be suitable for a fps game? \$\endgroup\$ Apr 17 at 12:43
  • \$\begingroup\$ "Will the packet be too large if they send a token each movement if the token is like 64bit" 64bit is nothing these days. \$\endgroup\$
    – Kromster
    Apr 17 at 12:57
  • \$\begingroup\$ The token does not need to be 64bit. Even a 5 digit token would be good enough. Remember it is just additional confirmation and the server does not need to confirm it. The attacker would not know if he guessed correctly or not \$\endgroup\$
    – Zibelas
    Apr 17 at 12:57
  • \$\begingroup\$ The encryption is only needed if you're worried about an attacker with access to the player's own network, or someone so motivated as to infiltrate an ISP just to hack your game. That's an issue for LAN parties, but for a game played over an Internet matchmaking service, it's very unlikely an attacker would be able to intercept and read packets sent to a specific targeted player in a specific match, so this might not need to be part of your threat model. \$\endgroup\$
    – DMGregory
    Apr 17 at 13:15
  • \$\begingroup\$ There are other benefits to encryption, like privacy and making it somewhat harder for a crummy ISP or school network to target game traffic to throttle/block. Ultimately the best way to find out if it's worthwhile for your use case is to construct a synthetic test and measure whether the overhead it adds is significant enough to worry about. \$\endgroup\$
    – DMGregory
    Apr 17 at 14:12

You must log in to answer this question.

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