If you have a mobile game that utilizes an in-game currency, you may want to think twice before building features that enable users to trade that currency. The reason is simple. It creates a security exploit and a 2nd hand market.
Let’s look at the most common example, that of a poker game. When the poker game is played against a computer, then the likely hood of it being exploited is far less. However when a poker game is played between two live people, there are many ways in which these in game coins can be traded and exploited.
One of the most common ways that in game currency trading is exploited is through a process known as currency bleeding. Let’s assume that you give new users to your game 30,000 coins.
As a user, I can sit on my computer and create two different accounts. As they are both new accounts, they each have the 30,000 coin starting amount. I then have the two accounts play each other within the game. During this play session, I have the 2nd account purposefully lose to the first account.
Once the 30,000 coins are drained from the second account and collected by the first, I simply ditch the second account never to be used again. I can repeat this process endlessly collecting as many coins as I want.
Now let’s assume that we have a mature user who has millions, billions or even trillions of in game currency. Since we now know that it is possible to move coins from one user to another, we run into issues with people stealing each others accounts and purposefully draining their accounts wallet into an alternate account. These thieves could be simply friends trying to play a practical joke, or they could be an actual identity thief working through social hacking and phishing attempts to gain access to a users account.
Believe it or not, there is a second hand market for selling high levels / high coin amounts within games. The reason why this market exists is simply due to the difference in the value of peoples time. A college or high school level student has a lot of extra time and little money. By contrast a working professional often has very little time and has a budget to dedicate towards disposable purchases. These two demographics meet. The busy working professional finds that they can buy a high level game board in their favorite game for $10 off of craigslist. They figure - why not. The seller then simply gives the purchaser their login information to the games account.
There are lots of other ways that a currency exchange feature can be used and exploited. Now that we know a few simple examples it is important to understand how to protect your game.
Whether or not you decide to include these features is up to you. Depending on the core game loop, you may decide that this feature is critical to the success of your game. Or you may decide that it is an unnecessary risk. The important part is that you weigh the cost / benefit of such a feature and decide if it is right.
If you do decide that it is right, there is a heavy layer of protection that you need to add into your game. We won’t be able to go into depth on all of them — but we can cover a few here.
The most important part is around statistics and tracking. First, you need to have good baselines of what the normal game play looks like. Both from an average perspective as well as from a user perspective. If a users game play session is normally 5 mins and only spends 10,000 in coins. Then alarms bells should ring when the user plays for more then 30 mins and is spending millions of in game currency.
The second aspect of tracking is understanding where the in game crunching in the game is moving to. In a basic casino game there is a notion known as RTP, or Return to Player. This is a players average of “for every 1,000 coins spent, the player gets x coins back”. Users who are skilled in poker will have a higher RTP, then those who are not very good at the game. If a user who has a high RTP suddenly sees their RTP drop consistently for an extended period, then red flags should be raised as that users account may be getting maliciously drained.
Keep track of user exchanges. In a normal poker player session, a single user will ultimately end up interacting with several users. There will be some wins, some losses, etc. Watch out for sessions where one single user repeatedly looses to the same player over and over again. This could be an indication of a coin exchange occurring.
Keep track of logins locations. In this sense there is nothing wrong with utilizing the user’s IP address to determine the users general location. keep a short history of the user’s login locations and watch out for immediate shifts. For example, if the user last logged in from Dallas, Texas, then 3 hours later, logs in from Turkey, there is a good chance that the users account has been compromised in some way. In this example you may want to take measures to either secure the account or temporarily disable it.
Have a way to quickly ban users. Even better is to have the system work in an automated fashion. The IP Address situation above is a great example of a situation in which you could ban a user in an automated fashion without too much difficulty. The coin movement examples will be a little harder to implement in an automated fashion and will require some fine tuning work.
When you are implementing automated banning, do so in a blind fashion first. Have the automated system flag the user as being banned, but do not actually ban them. At a later time have an analyst look at the player data along with the reason for being banned. Evaluate whether you are seeing correct assumptions or if you are seeing false positives. Make adjustments to your algorithms as needed.