0

We're running a popular social game and we have a security problem that is growing more and more popular these days.

We have the following product requirements:

  • There should be no registration to the game, simply giving Facebook permissions is enough (ie. no password, email validation, etc)
  • Players interact with each other using their scoped Facebook IDs
  • The servers must be highly scalable and support millions of players and CCUs

Unfortunately since the Facebook ID is our single way of identifying players, this opens up the following exploit:

  1. My friend did something that annoys me (I can easily access his Facebook ID / scoped ID)
  2. I create multiple fake Facebook users
  3. Even though these fake accounts aren't friends with my friend, I can simply send the victim's ID to the server and he will allow it, since we have no way of knowing this at the moment

The "obvious" solution would be to load the player's friends list on the server on login and store it (server to server is a big no-no for us + storing and loading huge amount of duplicated data from the database) - or loading the friends list on every action which interacts with other players and making sure they are friends (which causes for much, much more server to server actions).

We're looking for a workaround to this issue which will at the very least make it very hard to use this exploit, while not hurting our performance and scale.

  • You're missing steps between 2 and 3, I don't get what you mean. I assume any player can take any action against any other player, regardless of links of friendship. This is more a question for game design forums, but one common option for MMOGs is to sandbox new characters until they reach a certain age and/or level, so that they can't be affected by old characters and so that creating mules or fake accounts at scale is costly. – Steve Dodier-Lazaro May 10 '15 at 16:42
  • @SteveDL - the game works with a REST API which for example takes an attack on a player and his Facebook ID. It's meant only to be used by your friends. I've explained the "straight forward" solution which will kill our performance in high scale (so it's not an option) and was looking for a different solution or workaround – Ron May 10 '15 at 18:27
  • @SteveDL tl;dr; we want to make sure that player X is your friend on Facebook, but checking it every time/storing the data on the server is too expensive, and we're looking for a cheaper solution – Ron May 10 '15 at 18:29
  • As a rule of thumb if you need to enforce a security check, you should do it on the server-side. There are cases where you can restrict the actions of a client to a limited number of choices (using zero-knowledge encryption) but you need to spend the cost of verifying the challenges you send to clients. Maybe you could get attacked clients to do that, but then you need to resolve the case where such attacked clients systematically pretend they're unfairly attacked. In short: do it server-side anyway, and optimise / scale your code better. – Steve Dodier-Lazaro May 10 '15 at 19:00
  • @SteveDL, I'm afraid I didn't explain myself well enough. Let's say we have a certain JSON payload for a command to the game looking something like { Action: Attack, TargetFBID: "12345" }. I can simply change the TargetFBID and the server will assume I'm legit. Unfortunately if I will verify each request in front of Facebook, I will never be able to scale well (server to server will kill us). We currently peak at around 800,000 requests per minute and we can't afford to do that validation. I am however looking for a creative workaround to bypass it. – Ron May 10 '15 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.