🔒 Locked

Security Protocol for Multiplayer Game

Started by aykyo Mar 25, 2007 at 2:31 PM 11 replies 1.9k views

Original Post

Mar 25, 2007 at 2:31 PM

Hello, First let me say that I have 5+ years of programming experience in many of the 'standard' languages used today. However, I have only recently been exploring networking, so please excuse my naivety. Here is a little background: I am working on a very simple text-based MUD type game as a side project--I got into the project in search of new challenges and I certainly found them. Most prominently, I am puzzling over how to ensure communications between client and server are secure (ie, how can I ensure that messages from the client to the server are from a real client and not from some hacker?). Here is my setup: I am working in Java and using NIO for network communications. The game is open source. Messages are constructed and serialized into XML on the client side, then sent to the server. The server deseriallizes the message, performs the necessary processes (such as modifies a player's inventory, moves a player, checks for other players in a particular area, etc.). The resulting Object(s) if any are packed into a response, sent to the client as XML, deseriallized, and used as needed. Here is the problem: Since the game is open source, a destructive individual could create a 'special' client that deletes everyone's inventory (or something). None of the protocols I've looked at seem to prevent this. I've thought of somehow involving a dynamic hash of the client files, but even then a hacker could get the correct hash to send as validation pretty easily... Any thoughts? Suggestions? Web references? I would appreciate a little help! Thanks!

ToohrVyk

Mar 25, 2007 at 2:34 PM

Introduce server-side authentication, so that only a user who knows the correct password may access a given character. This doesn't prevent hacking, but at least your characters are safe unless you lose your password (at which point, even a non-hacked client can be used to mess with you).

aykyo

Mar 25, 2007 at 2:43 PM

Please excuse my negligence: I of course will be working an authentication system into the protocol (users will have to log in to a valid account).

ToohrVyk

Mar 25, 2007 at 2:53 PM

In that case, I do not see where your problem is: a hacked client could only affect a character if the hacker knew the owner's password, at which point a non-hacked client could cause trouble as well.

What can hacked clients do that normal clients can, in your game?

Antheus

Mar 25, 2007 at 3:02 PM

Before client is allowed any kind of action in the world, they must authenticate themselves.

Then, every operation they perform is tied to their account (some ID on server).

Every object on server will have an owner. If an object has no owner, you can consider it to be static, unchangable by players, or changable only by GM/admin/dev accounts.

Whenever a client performs an operation, you check whether the client's ID matches the owner of an object the operation is performed upon. If it does, perform the operation. If it doesn't, log a security exception.

Of course they can still destroy everything they own, but that's no different from someone using regular client to do that.

fenghus

Mar 25, 2007 at 3:09 PM

Depending on what you mean there are a few solutions...

Q Are you worried that a hacker compiles his own special client and uses it to abuse the game by duplicating items etc?
A Verify EVERYTHING on the server; ie. treat all client input as requests which may or may not be valid. Since the game is text based there shouldn't be a problem.

Q Are you worried that a hacker compiles his own special client and somehow replaces some other users client, forcing the victim to, for example, drop everything and self-explode?
A Pretty hard to solve; supply an MD5 hash of the download so users can verify it, but other than that it's difficult. Punkbuster?

Q Are you worried about man-in-the-middle attacks; ie. that messages from user X really originate from user X?
A Implement an authentication system; for example, have the client encrypt a symmetric key using the server public asymmetric key and use that to send login information. More on authentication here.

aykyo

Mar 25, 2007 at 4:09 PM

Quote:
Original post by ToohrVyk
In that case, I do not see where your problem is: a hacked client could only affect a character if the hacker knew the owner's password, at which point a non-hacked client could cause trouble as well.

What can hacked clients do that normal clients can, in your game?

This is a good point that I didn't think of (for some reason). If done right, a client could only ruin his/her own experience...

Although, if a hacker gave him- or herself 1000 of some super-excellent item and started trading them around... but then again, it would be pretty easy to detect such transactions and shut down the problem manually...

Thanks for the info everyone. If you have anything else to add please do!

Antheus

Mar 25, 2007 at 4:19 PM

Quote:
Original post by aykyo
Quote:
Original post by ToohrVyk
In that case, I do not see where your problem is: a hacked client could only affect a character if the hacker knew the owner's password, at which point a non-hacked client could cause trouble as well.

What can hacked clients do that normal clients can, in your game?

This is a good point that I didn't think of (for some reason). If done right, a client could only ruin his/her own experience...

Although, if a hacker gave him- or herself 1000 of some super-excellent item and started trading them around... but then again, it would be pretty easy to detect such transactions and shut down the problem manually...

Thanks for the info everyone. If you have anything else to add please do!

You do plan on doing all transactions server-side, right?

Client is merely a dumb terminal that renders the world. All transactions are executed on server. So even if client says it has 1000 items, the server will say they don't, and wouldn't even initiate the trade, since it wouldn't know about the items the client was trying to offer.

aykyo

Mar 25, 2007 at 5:07 PM

Yes, all the transactions will be done on the server. So I suppose as long as the authentication is done right, there shouldn't be too many problems.

redmilamber

Mar 26, 2007 at 11:21 AM

Quote:
Original post by aykyo
Yes, all the transactions will be done on the server. So I suppose as long as the authentication is done right, there shouldn't be too many problems.

Well, for a non-twitch game (as you seemed to describe) there shouldn't be *any* problems.

Your network protocol should be sending messages like:

C: inventory?

S: 400 x ID 1234513 [arrows]
10 x ID 365033 [wolf pelts]
1 x ID 035633 [iron sword +2]

C: trade item ID 365033 with player ID 4562 for item ID 6623423

S: trade pending (i.e. awaiting other player to initiate the identical opposite trade)

S: trade complete; inventory changed (i.e. the client needs to refresh its view of the inventory)

i.e. there's no issue of the client ever claiming that it has anything. In general, if your client can make claims of any kind, you have a bug.

Sadly, there are two kinds of claim that the client can make and you have to trust: whether or not it received a given message, and at what time it sent a message. If your game attempts to make things easier for players who suffer from delayed / inaccurate information (like e.g. an FPS), then it's customary to also limit the amount that a player can claim to be slow, and automatically kick them or - perhaps better - stop helping them when they go over that threshold.

For anything non-twitch based the answer is much simpler: you simply don't help them in any way for the fact that they have latency issues.

hplus0603

Mar 26, 2007 at 3:58 PM

Rule checking has to be done server side.

The client may invoke the function "get_item(item,room)," but the actual code executes server side, and the result gets relayed to the client. The server will then verify that item "item" is in room "room" and is pick-up-able, and that the player is in the same room, or return an error to the client.

You have to design the protocol used by the client such that they are all requests that the server has all the information about, and can make a fair determination about. Thus, "increment_gold(10000)" is not a proper function to expose in the public API. "pull_lever(lever)" might be OK; this would check that the player is close to the lever, and then run the script for the lever, and output the result to the user. The result of that script may be to give the user 10,000 gold, but the function to do so would not be exposed to the remote client.

I don't know what granularity you have in exposing vs not exposing functions through your RPC mechanism. You may need to code something specific like an interface with all client-invocable functions, implemented once on the client (to forward the message) and once on the server (to perform the action).

Afr0m@n

Mar 27, 2007 at 5:23 AM

Quote:
Original post by aykyo
Please excuse my negligence: I of course will be working an authentication system into the protocol (users will have to log in to a valid account).

If you haven't already implemented such a system, I suggest you look into the Secure Remote Password (SRP) protocol/algorithm for doing this. It is used by World of Warcraft (although in a modified way), and is generally very safe. Granted, the World of Warcraft protocol has been reverse engineered, but to my knowledge it would be very difficult to sniff the password of a specific user logging onto the gameserver if said server uses this algorithm.

hplus0603

Mar 27, 2007 at 11:08 AM

Any system which depends on the secrecy of the protocol for security is inherently insecure.

There is a very simple way to ensure no password leakage: implement a public key cryptosystem, and put the server public key in the client. The client encrypts the password with that public key. The server, which hopefully is the only one with the private key, decrypts the password, hashes it, and compares to a stored hash of the password plus some salt.

This is not rocket science. The main reasons games don't always do this is because public key cryptosystems are a PITA to implement. Or you can just go with OpenSSL, which in turn is a little bigger than you'd want from an ideal game authentication library...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.