1

I'm creating a game for a viral marketing campaign where roughly one in 100 players will get access to a QR code for some exclusive thingamajig. The game will require information to be pulled and pushed from the database since the game environment will 'grow' over time.

I haven't decided yet on how to do this, but I had 2 ideas, each with their concerns:

solution 1: connect the SWF to a database

concern: I have decompiled SWF's before and it is remarkably easy. How do I protect my database credentials against this?

solution 2: have the SWF connect to .php scripts that query a database. This way my database connection credentials are safe inside the php file.

concern: However, how do I then make sure the PHP script isn't being accessed by a custom script? Somebody could get the php URL from the SWF source and just access it directly, bypassing the flash app.

joon
  • 832
  • 13
  • 31
  • http://stackoverflow.com/questions/73947/what-is-the-best-way-to-stop-people-hacking-the-php-based-highscore-table-of-a-f – shanethehat Mar 27 '12 at 20:06

2 Answers2

2

You need to understand one thing.
Anything client side can be and if money is involved probably will be hacked.

With that being said, security is about layers, the more layers involved, the harder it is to be hacked.
There are many methods you can use and combine together that will take out of the picture the average swf hacker.

The first place I would start with is never ever store sensitive info in the client.(IE: server compiled SWFs)
If you have data there, it can be grabbed/modified.

Next, I would encrypt all data sent to and from the swf with a public key. This key would expire frequently. To obtain the key the swf would have to pass user credentials(login).
On the server side you can track the user via a session.

You can add socket connection support with a persistent connection
httsp, SSL, TSL
And many many more options to pick from.

The choice is yours.

The real question however, is how far do you want to go.

The_asMan
  • 6,364
  • 4
  • 23
  • 34
1

I would rule Solution 1 out right away for just the reason you identified.

So let's just talk about how to circumvent the solution 2 issues.

What I see is a common way to handle this is having the server side script handle the generation of these special items. If you look at a lot of online flash games, I'm sure you'll agree that Flash is responsible for the UI almost entirely, the rest is handled by the backend. This of course limits the type of games you can do this way.

There is also another way. If you could have your swf generated by your backend, you could store session data that would only be good for a limited time. This of course wouldn't have to be the same swf that stores all of your game assets but just the classes that are required to communicate with the backend. Generating the server interaction swf dynamically would then allow to store session important data and encrypting it with a different key every time, so that if someone does hack it, it would limit what they can do with it, as a new session would require new credentials.

Daniel
  • 34,125
  • 17
  • 102
  • 150
  • Instead of generating the SWF, I could send a session parameter to the flash project that is generated by the PHP page that will host the SWF... this way, my PHP side will know which sessions are alivem, and will only accept a score for each sessionID once. That might work... thanks for looking at it with me – joon Mar 27 '12 at 19:27
  • yes, but someone could make an app that handles the session data and can send whatever they like. You can encrypt the swf itself here's an example of that http://www.veryinteractivepeople.com/?p=525 – Daniel Mar 27 '12 at 20:03
  • I would +1 this but the server embeding data into the swf just wouldn't be good. Security should always be real time. Plus what happens if the user is playing the game for hours on end? Are they going to be reloading the swf every other minute to obtain the needed encryption keys? – The_asMan Mar 27 '12 at 20:04
  • you can set a timeout value, and require a new file/credential/session/token/etc. But all in all, as you say, anything can be hacked, and if money is involved it will be. – Daniel Mar 27 '12 at 20:15