Jump to content
  • Advertisement
Sign in to follow this  
aykyo

Security Protocol for Multiplayer Game

This topic is 4223 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!