Security in server-based multiplayer games

General Discussions
#1

In my game in the WIP section, First Recon, I host a server and any client can connect to it. It’s a fairly straight forward system.

I was wondering about how to stop clients that are not real from joining the server.

Currently I do a few sort of handshake checks. When the client connects, he sends his clients version number (major.minor.patch) in the form of a string. Then he sends his username. If that information is received in under 2 seconds of the established connection, then the client is allowed into the server and will spawn on everyone elses screen.

Since I released my game I’ve noticed on more than a few occasions people creating sockets manually to my server, or creating a socket and supplying incorrect data (resulting in a DC of the socket).

I some-what planned for this, and coded these things:

  1. The server asks the client to hash a bunch of variables to in integer and send to the server every couple of seconds. If this data is not sent, or is incorrect it results in a DC.

  2. The server requires you to send specific packets at a specific frequency (like movement). If you send outside of this frequency range, it results in a DC.

Is this enough of an initial security? I’ve never really dove into these kinds of topics. I know there isn’t a playerbase for my game, and it shouldn’t “matter” at the moment. However, I am still curious about the topic.

After I integrate an account system into the game, I’ll add an additional layer of security using a login-salt.

#2

I don’t see anything that a determined hacker couldn’t reverse engineer by simply looking at your code (which they can get, even if you’re doing things like obfuscating) and what’s sent over their network.

Can I take a step back and ask why you want to prevent clients from connecting to your server? You should be validating inputs on the server anyway, to prevent clients from doing anything they’re not allowed to do.

Anything done on the client side is exploitable by the user. There is no 100% fool-proof way to prevent clients from doing whatever they want. If you really want something to be secure, you have to do it on the server.

#3

No I know that someone with the client can reverse engineer it. That’s not what I’m talking about. I’m simply wondering if there are any articles out there that explore topics like these.

Everything is already validated on the server (position, shooting, health, ammo, ect).

I know there’s no way to foolproof an online game. I just want to strengthen it!

#4

My point is that all of the “security” you mentioned (hashing variables, sending packets) can be reverse-engineered, so they aren’t really providing much security.

#5

Well the variable hash is in case someone uses Cheat Engine to manipulate movement speed, jump height, friction, ect.
That’s the only reason it exists; for that specific case.

#6

[quote]The server asks the client to hash a bunch of variables to in integer and send to the server every couple of seconds. If this data is not sent, or is incorrect it results in a DC.
[/quote]
Letting the client calculate hash values is indeed very specific, your first line of defense should be strict plausibility checks on the server. You’ll catch cheat engine kiddies anyway if your (mentioned) plausibility checks on the server are any good.

You could go as far as the source engine does and run (almost) the entire simulation on the server and just let the clients pretend and correct.
Or have a nice light server architecture and easy programming instead of wasting time on security while there aren’t even players around.

Another important thing is vote-kick(with short ban) and admin tools, so that your player base can weed out hackers themselves.

#7

Two advices:

  1. People should use Google more :wink: , for example this great answer (and following) sums up everything: https://gamedev.stackexchange.com/questions/33922/prevent-multiplayer-cheating#answer-33924
  2. NEVER rely on “security through obscurity” :point: (please also google that term up) :slight_smile: