NYCPHP Meetup

[Dan Cech]

csnyder wrote:
> On Dec 12, 2007 10:32 AM, John Campbell <jcampbell1 at gmail.com> wrote:
> 
>> Initially the scores were send as a simple post request, e.g.
>> name=john&score=1000.  This is a problem because it is trivial to
>> forge the request.  So my solution was to create the post request as
>> follows:
>>
>> name=john&score=1000&checksum= . md5(md5("My secret") . name . score)
>>
>> on the server side, I can verify the checksum.
>>
>> This works well enough, but an enterprising hacker can download my swf
>> file and run `strings game.swf` to extract "My secret", and then they
>> can forge the request. Is there any cryptography method that
>> guarantees the request is coming from my code?
>>
> 
> Yes there is, John, but you may need to seriously consider whether
> implementation is worth it.
> 
> You can use a public/private key pair to perform asymmetric
> encryption. That means that a value encrypted using one key can only
> be decrypted using the other. This is the encryption scheme used for
> SSL, where your browser uses the server's public key (aka Certificate)
> to encrypt the request.
> 
> So you would use the game's public key to encrypt hash-of-score:random
> on the client side. And then on the server, you would use the game's
> private key to decrypt the value and check the hash.

Unfortunately this won't help.  If a malicious user wished to fake a
high score it would simply be a matter of extracting the public key from
the game and using it to create a bogus hash.

I do not know of any way to secure against a user with the capability to
disassemble the .swf.  Regardless of the mechanism used to create the
'secure' string for submission, the code to create that string must be
present in the .swf, and therefore vulnerable.

The degree of protection offered is really not dependent on the
encryption/hash method you use, but rather on how difficult it is for a
would-be cheater to figure out how to create the appropriate POST.

Without knowing the impact of a forged high score (eg can a user win
money by faking a high score?) it is difficult to make any
recommendation, but combining a simple checksum (using one of the
suggested methods to obfuscate the source of the secret portion) with
obfuscation of the .swf itself should give enough protection to thwart
casual attacks.

Dan