So I'm working on a web based game, and need to deal with the age old issue of duplicate account detection.

Players often create multiple accounts to farm money/items etc to their main account, or to stash items etc.

In the games I've typically played the main way this is done is by preventing multiple account to be used on the same IP within a certain window of days. If it happens repeatedly the newest account is banned.

The problem here in my mind is that the determined players just use a proxy, and it also prevents family members from both playing the game in the same home.

My idea, is to handle this another way. To keep a running tally of the 'networth' of items, money, etc that each account has given to another such as in trades, gifts, lost duels, etc as well as track the # of such interactions. Then if I detect accounts which have a large # of trades between the same two account with a growing networth traded from one account to the other (usually from the feeder account the the main one) I can then reasonably assume that these are suspected of being dupe accounts. If the amounts or small, and/or the frequency is small then it can be allowed.

Am I missing any glaring holes in this approach? I realize that small fish may stay under the radar, but these people would likely use a proxy anyway. And it will not prevent family members who make occasional trades between eachother.

  • 3
    You will catch duplicate accounts for banks, but not ones created to spy on other alliances. You will also misidentify farms as being duplicate accounts when they are merely regular victims. The bigger question is why duplicate accounts actually need to be prevented. If you look closely, the people who do it are probably your best potential customers. Why not take advantage of that? – btilly Sep 26 '14 at 0:04
  • Players will create even more duplicate accounts, so they can further launder the transfers and stay under your radar. The lower you set the thresholds, the more false positives you will have, swamping your problem detection. – ddyer Sep 26 '14 at 0:06
  • The solution to THAT is to make cheating detection soft, and then occasionally get a bunch of accounts. – btilly Sep 26 '14 at 0:16
  • 1
    I started on an answer and realised that it was too opinion-based. My 2c would have been to use SMS for account authentication for new accounts and periodically. That would be a relatively cheap way for you to increase the real-life cost and complexity for someone who wants to cheat by not specifying which account the auth code refers to in the message and by expiring the authorisation in an unpredictable way. – James Snell Sep 26 '14 at 0:25
  • 2
    Why don't you ask this question on gamedev.stackexchange.com? – Philipp Oct 26 '14 at 0:44

On the client, create a randomly generated "machine id" and set that as a cookie. Then send this value up with requests. This will avoid many of the issues you mention with IP addresses. (Though not all.) On the server, you can maintain a list of all machines associated with a given account. If you see the same id on two different accounts you know that both accounts were used in the same browser under the same local account on the same machine. You still might have false positives as family members sometimes don't bother with separate accounts, but it should be a lot better than IP.

Of course, this is something a savvy users can pretty easily avoid, so you'd want to keep this soft and give no indication on the client that you are doing this. You probably want to make it look like this device id is just part of the sign in process. (For instance, sign the user out of the game if the cookie goes missing.) If you use some sort of cookie-based session mechanism then embed the machine id in the session id.

If the user doesn't notice the cookie before creating the duplicate account, you can catch proxy use by seeing the same machine ID come from two different IPs. (Though this again can have false positives.)

You idea of looking for "cheating behavior" isn't bad as long as you make sure to keep a human in the loop. Use this to trigger alerts for those humans. Once a human is in the loop, they can catch patterns that no computer ever will. For instance, one player consistently making profoundly bad trades to another player.

A lot of this sounds like "Security by Obscurity". It absolutely is. In a web-based application, the user has huge amounts of control of what runs and so no real security scheme is feasible.

  • How would that work if someone was using chrome with an "in-cognito" session? – Michael Riley - AKA Gunny Apr 20 '15 at 17:11
  • It wouldn't. As I said, "Of course, this is something a savvy users can pretty easily avoid". – Gort the Robot Apr 20 '15 at 17:12
  • Once a human is in the loop, they can catch patterns that no computer ever will. For instance, one player consistently making profoundly bad trades to another player - hm, this sounds like something easily detectable by an algorithm. Unless I am misunderstanding you somehow – Konrad Morawski Apr 20 '15 at 18:48

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.