0
\$\begingroup\$

Consider a multiplayer (client/server) game where you initiate the construction of some building. Let's assume construction will complete after 60 minutes.

My plan for dealing with this information is as follows, but I'm not sure if it is secure:

  • Client initiates construction of building (60 mins)
  • Server accepts request (resource requirements are met)
  • Server stores the building task for that player and a completion time-stamp (now + 60 mins)
  • Client begins a countdown (60 mins)
  • If client re-connects, the completion time-stamp is retrieved from the server and the remaining time is calculated by the client
  • When the client counter hits 0, it asks the server for an update
  • While retrieving the data to send for an update, the server notices that the time-stamp has expired and makes the necessary updates
  • Server response includes newly constructed building

I thinkit is secure since the completion time and resource calculations are all on the server side; however, is there a security problem that I haven't foreseen?

\$\endgroup\$
  • \$\begingroup\$ This seems like a sensible way of doing things in terms of server performance, however, i'm assuming b the nature of the example that this is a mobile game, running timers is not the best way to do it. Storing the start time and simply checking this against the current time when the user opens the app is likely the best way to this. \$\endgroup\$ – Lex Webb May 14 '14 at 15:54
  • \$\begingroup\$ Questions asking for a the "accepted ways to do things" are list-generation questions and not generally suited here. It's also usually not appropriate to ask "here's my plan, what do you think." However, the query about security issues does make the latter slightly more on-topic, so I have edited your question to better focus on that instead of the off-topic queries. \$\endgroup\$ – Josh May 14 '14 at 15:57
  • \$\begingroup\$ I can see ways it can potentially be abused dependingon how other game mechanics are. Not sure if that is what you mean by secure. When I think of security I think of gaining unauthorized access to something. \$\endgroup\$ – ClassicThunder May 14 '14 at 16:06
  • \$\begingroup\$ What do you mean by "security", in this context? What, precisely, are you trying to keep secure, and from whom? \$\endgroup\$ – Trevor Powell May 15 '14 at 5:15
  • \$\begingroup\$ In this specific example, security == cheat prevention. \$\endgroup\$ – Michael Robinson May 15 '14 at 12:57
3
+50
\$\begingroup\$

The security implication you are worried about is a 10 year old changing the clock on their device to cheat the system. My daughter when she was 5 learned how to change the time on her iPod to get a new batch of coins in Coin Dozer. So it is a valid concern. But you have to count the cost. My goal is to reduce cheating by making it harder. To me it's not worth a lot of extra server processing to try to make a 100% system. And that's impossible anyway.

As Lex said, timers isn't the way to go. If you have 1000 users each building 5 things you're going to be running 5000 timers on the server? NO. What if you have 100k users. Use MATH! This is how I would do it:

  1. Client occasionally gets game economics table from the server which includes time to complete building of each object type. This way you can change the economics after the game is released if you determine that an adjustment is needed or to stimulate sales.

  2. Client also gets the time from the server on boot or entering foreground if it can and stores the offset between server time and client time. From then on server time can be estimated using client time.

    Also if the device/client is offline the game still should be playable. Don't screw the 10 year old just because you're worried about cheating. Update the offset regularly and when you can, but if you can't use the last stored one. And look for cheaters by seeing if the time goes backwards or if the offset changes a lot. You can always put in code to require a server check only if it determines that cheating was attempted.

  3. User initiates construction of a thing that takes D time according to the table.

  4. If your device doesn't allow time changing without exiting and re-entering the app, you don't need to check the server time per new construction. (The iPhone can't without jailbreak) Just use the offset to estimate the server time (S).

  5. Store the target time (T) when construction will be completed - client side. Checksum or hash or something to protect hacking that time if you want.

  6. You can then calculate % complete using your estimated server time, the duration to build from the table, and the stored target completion time.

    % complete = D-(T-S) / D. If this is more than 1.0 construction is complete.

  7. Then if you want to store all this activity on the server, queue up messages to tell the server after the fact.

  8. Alternatively you can check the server time repeatedly instead of estimating it, but it's going to bog the server down and cause lag on the game and then people will stop playing.

Lessons I've learned:

Do as much processing on the device or console as possible. Cause you only have 1 server and you might have 10k or 1m clients. Don't design so that your server can only handle the processing if you're game isn't successful. "If we're successful we'll buy more servers" isn't a winning idea.

Security to prevent cheating in a game is important, but reasonable security is enough. If your game is so popular that 1000's of people are cheating it - you'll be making money.

I use weird proprietary security algorithms. Hackers are better at cheating standard methods than something weird you just thought up.

\$\endgroup\$
  • \$\begingroup\$ There's probably a simplified version of that % formula, like (T-S)/D give you % remaining. So 1 - (T-S)/D give you % complete. And percent is 0 - 1. \$\endgroup\$ – badweasel May 15 '14 at 0:22
  • \$\begingroup\$ "I use weird proprietary security algorithms. Hackers are better at cheating standard methods than something weird you just thought up." Weird does not mean secure. Hackers are better at hacking a method you've thought up because your method isn't theoretically nor practically proven to be secure. \$\endgroup\$ – Howie Aug 8 '14 at 10:46
  • \$\begingroup\$ It's debatable. Standards can mean less secure because everyone knows the method. It's like buying a lock from a place where all the keys are available online. Like if I use a proprietary way of scrambling and salting hash, one that I make up and don't publish anywhere. That's more secure than using something that is published on GitHub. \$\endgroup\$ – badweasel Aug 9 '14 at 19:11
  • \$\begingroup\$ And my other point is that "secure" is relative based on the use and level of security needed. This guy wasn't protecting bank accounts. I wouldn't give that advice to my bank. \$\endgroup\$ – badweasel Aug 9 '14 at 19:14
1
\$\begingroup\$

Badweasel correctly pointed out that this solution would require excessive resources for little effect, but you have asked for what security issues remain on your solution.

Let's look at the typical avenues for cheating, more or less by order of difficulty:

  • Change a user-editable value like the system clock. OK, This is what your algorithm is intended to protect against.
  • Directly edit the game's saved file/data files. Works if the player is just changing the time-to-completion, but not if he sets the building to be already complete.
  • Direct memory access, through a trainer or similar program. Easy on Windows, harder on Unix/OSX. No effect.
  • Spoof entry/exit packets; change data packets as they leave/enter your network. Protects vs. outcoming, doesn't protect vs. incoming.
  • Spoof client; fake client program sends data to your server. May make things worse, as it opens your system to DDoS-like attacks.
  • Spoof server; redirects your server's IP to a fake server that sends custom packets to your application. No effect.

I've probably missed a few common cheat methods, but you can see how you've barely dented the problem.

\$\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.