0
\$\begingroup\$

I am designing a server-client model game library/engine.

How do I, and should I even bother to handle frequent update packet possible impersonating?

In my current design anyone could copy a packet from someone else and modify it to execute any non-critical action for another client.

I am currently compressing all datagrams so that adds just a tad of security.

Edit: One way I thought about was to send a unique "key" to the verified client every x_time and then the client has to add that to all of it's update packets until a new key is sent.

Edit2: I should have mentioned that I am not concerned about whether the actions described in the packet are available to the client at the time, this is all checked by the server which I thought was obvious. I am only concerned about someone sending packets for another client.

\$\endgroup\$
4
  • \$\begingroup\$ "A server-client model game library/engine"? Which is it? Why not use the easy option of TCP with an SSL envelope? \$\endgroup\$
    – Anko
    Commented Mar 8, 2014 at 11:50
  • \$\begingroup\$ @Anko Doesn't matter which it is. And I prefer to handle all my data myself instead of relying on slow protocols like TCP \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 17:53
  • 1
    \$\begingroup\$ Design the game so sending fake packets doesn't matter. \$\endgroup\$
    – Vaughan Hilts
    Commented Mar 8, 2014 at 17:59
  • \$\begingroup\$ It's foolish to dismiss "slow" protocols with well-implemented security. Almost by definition, getting security requires a speed tradeoff. The real question is how much security do you want (and what kind of attacker are you trying to deter), and how much speed are you willing to sacrifice? This is the only way to answer either of your two questions, how and should. Can you give any more context to that effect? \$\endgroup\$
    – Seth Battin
    Commented May 7, 2014 at 21:37

3 Answers 3

Reset to default
1
\$\begingroup\$

Yes, you should definitely prevent this, because it makes cheating very easy.

There are countless ways for a cheater to manipulate the network traffic sent from their machine. For example:

  • Hooking of network APIs of the operating system
  • Play man-in-the-middle on their network router
  • Hacking your game client
  • Cloning your game client
  • ...

You might consider to just tell the users of your library/engine to slap an anti-cheat tool on their game when they don't want cheaters, but 3rd party ACTs are just an excuse for people who don't know how to develop inherently secure client/server applications. Also, when you search on this website for information about anti-cheat tools you will realize how flawed they are.

Never trust the client. The client is in the hands of the enemy! Each incoming network message should be examined carefully to check if that very client is allowed to perform that very action at this very moment, and reject it when it doesn't.

When you use the TCP protocol, each client has their own connection, so determining who sent the message is trivial. UDP is connectionless, but each UDP datagram has a source-IP and source-port you can use to determine its origin. When your client library doesn't create any new UDP sockets, these shouldn't change during a session.

When you want to be really paranoid, you might consider encrypting the network traffic with a stock encryption algorithm (never invent your crypto unless you have at least a Ph.D. in math and computer science) and a different key for each session exchanged using the diffie-hellman key exchange. But that level of security is usually overkill for a game and not worth the added complexity and performance overhead.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ I should have been more clear on my problem. I am not concerned about the data the client sends, but only about someone else sending data for another client. \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 17:54
  • \$\begingroup\$ Also I believe the source in the datagram is only part of the packet so it can in fact be anything including false address. \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 17:55
  • \$\begingroup\$ @TheDespite IP address spoofing used to be a problem in the past but nowadays almost all internet service providers prevent this. \$\endgroup\$
    – Philipp
    Commented Mar 8, 2014 at 18:23
  • \$\begingroup\$ Philipp: Any source for this? Would be nice if I could just check the IP:Port to make sure the source is valid. For some reason I can't use (At)Philipp \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 18:28
  • \$\begingroup\$ @TheDespite FWIW, you don't actually need the @ to ping Philipp, see meta.stackexchange.com/a/125212 \$\endgroup\$
    – bcrist
    Commented Sep 22, 2015 at 5:15
0
\$\begingroup\$

One way I thought about was to send a unique "key" to the verified client every x_time and then the client has to add that to all of it's update packets until a new key is sent.

What if the client doesn't get it, or gets it very late? Probably better to establish a key per-session and call it a day. For example I encrypt all data using a per-session AES key due to the low overhead, but I don't claim to be a security expert.

Also don't broadcast network information about the clients to each other, only the server needs to know. The last thing a multiplayer game needs is multiple players DoS'ing each other.

\$\endgroup\$
7
  • \$\begingroup\$ Sending the new key over TCP and overlapping it with the old one for a while will ensure that if the client still exists it will recieve the new one. Would double as an alive-check. \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 17:56
  • \$\begingroup\$ Again I think I wasn't clear enough. I'm not broadcasting data to other clients, hence the client-server model. \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 17:57
  • \$\begingroup\$ There's still no need for it though, that's redundant security. You may want to think about how someone will actually attempt to crack the connection. Say I establish an AES-encrypted connection between client and server. At that point a brute force won't work, only exploiting the client or the server will. At that point changing the keys won't make a difference. It will only cause issues for players without a perfect connection. \$\endgroup\$
    – user39686
    Commented Mar 8, 2014 at 18:09
  • \$\begingroup\$ What do you mean by "cracking the connection"? I don't care if the packets can be read by a man in the middle if that's what you mean. \$\endgroup\$
    – TheDespite
    Commented Mar 8, 2014 at 18:34
  • \$\begingroup\$ Aye, but we do care if the packets can be sent by a man in the middle. If someone reads your attempt to secure the connection, then they can break the security. \$\endgroup\$
    – user39686
    Commented Mar 8, 2014 at 18:36
0
\$\begingroup\$

If you are using TCP then you should be able to determine which connection the packet came over (from what address it originated). So you assign each player a unique id and associate that with the connection id. Now for each packet, you can do a lookup on the server, and make sure the id/connection pair is valid. That is an easy fix for the problem you describe.

\$\endgroup\$

You must log in to answer this question.

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