Per your comment, "...even easier to fake on the client-side." Unless it involves elements generated on the server side which are verified against established samples such as...
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 the last token and arrive at a mean score that doesn't deviate from your 'curve' more than [n]%. Statistically, this reduces system threat significantly - further hardening will require an obstacle course. My recommendation on using a screen capture was to help verify being 'in-game' vs. 'in-script.' "...anything your Flash client code does can be done by a hacker's client." - not accurate. Should read, "...score submissions from your Flash client can be simulated by a hacker's." The trick is to make the process complicated enough to reveal counterfeit submissions. No method is going to be perfect... with enough time and persistence any system will eventually fail. The point is to find a balance between security and the prize. In my travels I've found a wide variety of solutions: Implementation: The use/exchanging of tokens to ensure that the data received followed a prescribed path. Challenge: A server-side request for known [data]. The map hack used in Warcraft is discoverable if the server requests that the client send a random 'known' pixel value... that does not conform to a spec. Obfuscation: The use of specialized protocols to keep data less than human readable (cryptic). Statistics: The process of comparing data received against known or projected values (e.g. deviations) to reveal potential counterfeits. Sampling: The act of repeating statistical analysis throughout the process to further harden implementation. Identity: The use of data/information that uniquely identifies an individual. If necessary, ask for [info data] up-front - which establishes an identity that can be linked/locked/paired with implementation (hardening). The value of identity data should parallel system value (i.e. a cookie can be used to track identity - serviceability is increased by adding a credit card #). Identity data can be anything from cookies, email addresses to user accounts. Identity is the most expensive as it may result in increasing the value of your system - requiring further hardening. Programmability: The use of techniques that are not easily duplicable by a computer (i.e. Captcha). 'Secret Sauce': Encryption, digests, etc. used at any stage in any approach to further harden data. About your last comment. Scores in any game either start at 0 (zero) or some max value. Over game play the value increases/decreases until the game ends. Scores plotted against time reveal a positive/negative inverse exponential curve. Skill is a function of a particular time-slice. So... in golf - a player's score can never be less than (perfect attempt + handicap). Handicap is used to normalize deviation. Etc. etc. etc. Rick Winscot -----Original Message----- From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Troy Gilbert Sent: Wednesday, May 28, 2008 10:39 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] 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 an extra hurdle - you could > watermark the image with the server time and limit the submission window to > say. 5 minutes from the end of the game. That wouldn't work at all. First, anything your Flash client code does can be done by a hacker's client. The client cannot be trusted, no matter how complicated you make it. Any of the aforementioned ideas would be excellent deterrents for most hackers. The above technique would require a great deal of R&D on the server-side but would be even easier to fake on the client-side. > On the point of score validation. scores in any video game are inversely > exponential - any score that deviates from the mean curve can, with a high > degree of certainty, be flagged as invalid. In order to do this correctly > you should be keeping total game time (y axis) and the total score (x axis). I'm not sure how you can say that scores in any video game are inversely proportional. What about a golf video game? ;-) Troy. ------------------------------------ -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links
