] The High Score Problem
Take a screenshot with the score and base-encode it, take a digest
(signature) of the whole of it with the score plus some 'secret sauce' as
a
seed value and then send the lot of it to your server and re-run the
process
to see if what you received is valid. To add
The problem would be solved if we knew how FMS 3 does SWF Verification. My
guess is that it works something like this:
- NetConnection.connect sends a hash of the swf that has been loaded
- Server creates a hash of a copy of the swf that has been placed on the
server
- If the hashes match, access
On Thursday 29 May 2008, Rick Winscot wrote:
At the start of game request a token from the server - persist that on the
server with the time it was requested. At the end of game request another
token. To successfully submit the score you will need two valid tokens,
submit within [n] minutes of
Https is only good against man-in-the-midle attacks, not when the client is
the attacker.
On Thu, May 29, 2008 at 10:30 PM, Tom Chiverton
[EMAIL PROTECTED] wrote:
On Thursday 29 May 2008, Rick Winscot wrote:
At the start of game request a token from the server - persist that on
the
server
On Thursday 29 May 2008, Josh McDonald wrote:
Https is only good against man-in-the-midle attacks, not when the client is
the attacker.
Aye, as I've said several times, sometimes to incredulous looks. And even
*then* who actually uses client certificates / checks the certificate hash ?
As part
This has been debated *eternally* in game circles since the advent of
networked games, and I've followed these discussions for at least the
last decade. The conclusion is always the same and is not disputable:
in a broad-based, open competition (such as a web-based game for
prizes, e.g. a casino
don't use SWFEncrypt on the scoring SWF until right before you send it
to the user and have SWFEncrypt use a different seed value for its
obfuscation; this ensures that the SWF's checksum (or any other
fingerprinting the user could do on the SWF) can't be used to detect
repeats in the
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] The High Score Problem
This has been debated *eternally* in game circles since the advent of
networked games, and I've followed these discussions for at least the
last decade. The conclusion is always the same and is not disputable
Tom hit on a key point - the value of your data (high scores) needs to
parallel your security mechanism. I have an idea that I haven't seen anyone
touch yet.
Take a screenshot with the score and base-encode it, take a digest
(signature) of the whole of it with the score plus some 'secret
Take a screenshot with the score and base-encode it, take a digest
(signature) of the whole of it with the score plus some 'secret sauce' as a
seed value and then send the lot of it to your server and re-run the process
to see if what you received is valid. To add an extra hurdle – you could
I've ben struggling with this as well. The issue is not with Flex; you'll have
this with any client server application.
You even have a bigger issue than what you are outlining...
The components you have to expose on the server can be directly accessed by a
skilled programmer without using
11 matches
Mail list logo
