Server-Side Authentication in Unity?

Hi all,

My game requires users to log in via Facebook in order to get past the start screen because this free-to-play game has real prizes to be won, and having their Facebook details provides a means of contacting them if they win.

I've been pondering security and how I might prevent a hacked version of the game from submitting guesses that could allow them to win. A user submits a guess via my web API using the WWW class, and my code returns a simple yes or no bool value, as to whether or not they guessed correct (and won a prize).

When submitting a guess, my API currently requires the user's Facebook ID that is returned by the Facebook API, along with their guess. I have server-side checks to ensure a single user (Facebook ID) can only submit 1 guess every 5 seconds, but what is to stop a hacker from sending a bogus Facebook ID that they randomly generate?

My initial thoughts are that on logging in to the app via Facebook, I should server-side query Facebook for that user's first name, last name, friend count etc, and generate a hash on the server, storing it in the database. Any API requests within the game should then send along those same details, which i'll hash on the server and compare against the stored hash in my database. If the hashes match then I can assume the account is at least a genuine one.

But, what stops a serious hacker from implementing a Facebook user lookup function into their own hacked version of the game, and sending legit details along that will pass my server side checks?

One has to ask themselves, why would a hacker submit guesses from someone else's Facebook ID, and potentially winning a prize for that person? Perhaps someone with thousands of Facebook accounts? I don't suppose there is a way to protect against people who submit attempts from thousands of seemingly legit Facebook accounts, other than applying some limitations on the number of requests coming from the same IP - but with proxies even that's not foolproof.

I'll conclude by suggesting that in the event a successful guess is submitted, a "claim code" is generated and given back to the user, and stored in the database. In order to claim the prize, the user would need to quote the claim code they were shown in the app. This means that if a hacker won the prize on someone else's behalf, the unsuspecting winner would not be able to claim the prize.

It makes my head spin, but if you've made it this far through my post, thanks! If you have any feedback on my thoughts, or a suggestion as to how I can guarantee legit usage of my game i'd love to hear it.

[ UPDATE ]
I just found that the Unity Facebook SDK returns an access token when the user successfully logs in (FB.AccessToken). On the server I can query the Facebook Graph API for a user by passing a valid access token, so this is how I will authenticate each request. As for dealing with spammers with multiple accounts, i'm still not sure on a best approach.

Thanks

Mat

 

Is it a mobile game? You could use device ID to ensure that multiple guesses cannot come from the same device in x period of hours or minutes. You could also ban devices by ID if they are submitting faster than humanly possible.

 

It is a mobile game yes. However, if a unity game is hackable then what stops them from changing the device id in their request?

I've got the ban hammer at the ready as my user table in the database has a banned field

 

You could have the app send device ID on first launch to the server, where it would be stored and used to validate future guess requests. They could then fake the initial request to add a fake ID, but you could have the request include a hashed passphrase that exists in the app code, which is validated once the request is sent. They'd then have to reverse engineer the app or capture the packets to find the hash. You could salt the hash with additional data based on the state of the app when the request was sent, like maybe time of day or day of week. The sever-side code would know the scheme for salting so it could validate the hash. That way they'd have to figure out your salt scheme as well.

Your game will always be hackable it's just a matter of how far you want to go to thwart it, and staying a step ahead of people. Some additional measures could be SSL or some other packet encryption and code obfuscation.