0
\$\begingroup\$

When a client first connects to the server a Diffie-Hellman key exchange occurs to securely get private encryption keys to encrypt all packets.

The problem comes in: what if someone sniffing packets resend a "move right" command? Since they are simply resending the packet the encryption is still correct, and since movement commands can come at anytime, multiple times, the server cant just ignore multiple of the same packets.

Q: How do i prevent a packet-sniffer from replaying a move-right player command.

Edit: would the answer be timestamps included in the encrypted message? and then maybe any movement commands that are older then 500ms are dropped?

\$\endgroup\$
  • \$\begingroup\$ What's your threat model here? Who is this party who benefits from using a packet sniffer and replaying a player's commands? If it's the player themself, then the player can just enter those commands in the game. If they try to perform that action when it's not allowed, your server should reject the command, whether it's a replay or no. \$\endgroup\$ – DMGregory Nov 30 '19 at 22:38
  • \$\begingroup\$ @DMGregory i was thinking what if i developed a game with instant-killing traps. A troll could potentially develop an software to replay any sniffed movement commands to scramble other players movement and get them killed, nonetheless decreasing their experience. This is also an authoritative client-server model. \$\endgroup\$ – DiscreteTomatoes Nov 30 '19 at 22:45
  • 1
    \$\begingroup\$ How would a third party sniff packets that are not going through their computer? \$\endgroup\$ – DMGregory Nov 30 '19 at 22:48
  • \$\begingroup\$ @DMGregory im not sure, i assumed since the internet is like a web with everyone passing on the data to the next person until the packet arrives. Maybe someone can sit there idly seeing packets passing by and maybe identifying one that belongs to my game? and replaying it? as you can see im no expert. \$\endgroup\$ – DiscreteTomatoes Nov 30 '19 at 22:51
  • 1
    \$\begingroup\$ The parties between your players and your server are the Internet Service Providers and the internet backbone servers. Not folks who are known for trolling individual players in games, let's say. I'm not sure this is a real problem that you need to solve. \$\endgroup\$ – DMGregory Nov 30 '19 at 22:53
3
\$\begingroup\$

The most likely way such packets could occur is through cheats that people would code for your game. Either the cheat would hijack the connection on the client's side and send duplicate packets, or your client itself would be compromised by the cheat and send whatever the cheater wanted. No amount of encryption can protect against that, but what helps against both these approaches is making sure that if the server receives more packets, it doesn't mean that more things happen.

The best way to do this would be to write your netcode such that each player sends only one packet per tick, containing all actions the player performed during that tick. This packet should contain the number of the tick those actions occurred on. Then your netcode could filter out any inappropriate packets by tick (ignore packets whose tick is not unique, or whose tick number is a lot too early or too late for the current game time).

It needs to be verified separately that the actions can all be performed by the player in that tick, but that verification should strictly be part of your game code and not your netcode. Also, client packets may arrive at the server out of order, so you should take care to process them in order via some method, but how to do this properly is beyond the scope of your question.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.