Securely provide a unique secret code to winner of flash game?

Question

Here's what I want to do: when a player wins a game (coded in flash/actionscript), they are given a personalized secret key, which they can email to me in exchange for a prize. I can then validate the key on my end using a private algorithm.

I need to design it so that it is practically impossible for hackers to generate a valid prize key without winning the game. Is this even possible?

I assume that any SWF file is basically vulnerable to decompilation, but I don't know exactly how vulnerable they are. Perhaps any algorithm for generating a valid key will be accessible to hackers?

I have at my disposal all the methods in actionscript 3, as well as a PHP/MySQL server, and I control the server where the game will be hosted.

Answer 1

What you really want to do is to securely determine the winner of the game.

That's hard, but, depending on the game, you can try to:

• continuously validate the state of the game with the server (doors opened, rooms entered, coordinates on the map, etc), especially with regard to the timing (how long it should take to move between coordinates);

• determine whether the game will be won or lost in advance (e.g., scratch cards);

• ask the winner questions about the game ("what colour was the cow?").

Answer 2

^{Disclaimer: I don't work with flash.}

When starting the game I would obtain a unique token from the server. After they win the game I would generate a code using that unique token and display that to the user. Then you can validate the unique code against tokens from the server.

Another thing you could do is incrementally "build" the unique code as they play the game. If they don't play it through they will at the very least have to backtrack through the entire game to generate a code.

I would say most games are vulnerable in some form to decompiling, the goal is to minimize loss. If you're giving away high value prizes then of course you will be targeted by unscrupulous people.

Answer 3

Keep the key generation server-side. Even if it's a simple md5 hash, keeping the exact generation details secret is critical. Add a few random characters to whatever hash you do generate, so it won't LOOK like an md5 or sha1 hash.

Of course, then the problem turns into "how do I know the user really won the game"? Decompiling the .swf would let a determined user figure out that you send "won=1" and boom, you get a winning key code back, at which point the game's over, so to speak.

To give you an idea of how hard this can be:

Years ago there was a site that offered dinky flash games you play and win points that you could exchange for prizes. It was horribly sloppy in its coding, to the point where you had to question the sanity of the site's operators. Some of the major flaws:

1) There was a daily survey. A single question with a few choices. They put the point value of the question into the survey form as a hidden value. It was submitted via GET. You could manually build the response and give yourself MAX_INT points once a day, just by doing "response.php?surveyID=XXX&choiceID=YYY&points=4294967295" in the address bar

2) They clued in to that relatively quickly, and fixed the points hole, but for some reason removed the daily limit, so you could submit your answer as many times you wanted for (say) 20 points a pop.

3) After they fixed that up, people moved on to hacking the games - playing the game and winning around would give you (say) 100 points. Here they were a bit smarter at launch and weren't round-tripping the point value through the client. But they forgot to validate the number of times played, which was kept client-side - so you could claim 100 points as many times as you could fire off a POST at their server

4) After fixing that and moving the "times played" count to the server, people just kept their bots submitting the games' particular limit, but submitted bogus claims for EVERY game on the site

5) After they started putting checkpoints into the game (e.g. "tell server level 1 completed", "look, they just finished level 2" etc...) people simply added the checkponit messages to their point stealing bots.

and so on down the road...

If you're going to start doing prize claims with prizes of any sort of value, be aware that you'll probably have many many attempts at sucking your budget beyond bone dry within short order.

Answer 4

Short answer is:

You can't.

Long answer:

Since one of the bits of information you use to determine a winner is the game itself and because the game itself is compromised from the start, you can not determine if the user has completed the game if the flash/actionscript determines the win state. Even if the script asks the server for secrets along the game path to determine the win state, you can still simulate this and hence you can't be sure if your server is responding to a real person playing or a script that's been decompiled and someone playing out the responses by hand.

What you can do:

Make it harder for people to fake responses, have the script give you a full move by move output log to analyze, use a one time pad in each download of the game to validate that it was the winner, keep a timer running to ensure players took a full time to play the game... other ideas presented in this thread are also good.

Sorry for the bad news.

Answer 5

First off, don't give the user a "secret" code to validate.

When delivering the page to the client create a "secret" code. Probably a base64 encoded GUID would work. Record the guid, when it was generated, and the browser fingerprint in your database.

Once the game is over have the action script get their details for prize delivery. Post this back to your server along with the code. Again record the date time of completion and the browser fingerprint.

To validate, check the amount of time that passed between guid generation. Also look at the browser fingerprint.

Cheaters will stand out in three ways. First, the date/time delta will be extremely short. You should know how long it normally takes to play. Second, you might see a host of posts to your page with invalid codes. Third, the browser fingerprint might even tell you who was using automated tools.

UPDATE
I just wanted to point out a couple things you will want to include. First, @aaz had a great idea about asking the player a question about the game at the point they are filling out the winner information. This should be some element that is randomized. Probably not color simply due to the number of people who are color blind; but certainly something you can control and record server side prior to delivering the action script. At the very least this would require some level of human intervention when posting results.

Second, @John Lewis had a good idea about recording their in game actions and submitting those. Perhaps any click coordinates could be saved and immediately sent back to the server and saved with a date/time stamp. You could compare those coordinates across multiple games to look for patterns. Intelligent analysis will be important.