根据我的经验，这最好是一个社会工程问题，而不是一个编程问题。与其专注于让作弊变得不可能，不如专注于通过消除作弊动机来让它变得无聊。例如，如果主要动机是公开可见的高分，那么简单地延迟高分的显示时间就可以通过消除作弊者的正反馈循环来显著减少作弊。

我通常会在高分条目中加入游戏回合的“幽灵数据”。所以如果我在制作一款赛车游戏，我就会包含回放数据。你通常已经拥有关于重玩功能或幽灵赛车功能的重玩数据(游戏邦注:与你的上一场比赛进行比赛，或与排行榜上排名14的玩家的幽灵进行比赛)。

检查这些是非常费力的工作，但如果目标是验证竞赛中的前10名参赛作品是否合法，这可能是对其他人已经指出的安全措施库的有用补充。

如果你的目标是将高分列表保持在网上，直到时间结束，而没有人需要查看它们，这不会给你带来太多好处。

It is only possible by keeping the all game logic at server-side which also stores the score internally without knowledge of the user. For economical and scientific reasons, mankind can not apply this theory to all game types excluding turn-based. For e.g. keeping physics at server-side is computationally expensive and hard to get responsive as speed of hand. Even possible, while playing chess anyone can match AI chess gameplay to opponent. Therefore, better multiplayer games should also contain on-demand creativity.

您不能相信客户端返回的任何数据。验证需要在服务器端执行。我不是游戏开发者，但我确实制作商业软件。在这两种情况下，都可能涉及金钱，而且人们会破坏客户端混淆技术。

可能会定期将数据发送回服务器并进行一些验证。不要把注意力集中在客户端代码上，即使您的应用程序就在客户端代码上。

没有办法使它完全不可攻击，因为它很容易反编译swf，一个熟练的开发黑客可以跟踪您的代码，并找出如何绕过您可能使用的任何加密系统。

如果你只是想通过使用TamperData这样的简单工具来阻止孩子作弊，那么你可以生成一个加密密钥，在启动时传递给SWF。然后，在将高分传递回PHP代码之前，使用http://code.google.com/p/as3crypto/之类的东西对高分进行加密。然后在服务器端解密，然后将其存储到数据库中。

一种简单的方法是提供高分值的加密散列及其本身的分数。例如，当通过HTTP GET发布结果时: http://example.com/highscores.php?score=500&checksum=0a16df3dc0301a36a34f9065c3ff8095

当计算这个校验和时，应该使用一个共享秘密;这个秘密永远不应该通过网络传输，而应该在PHP后端和flash前端中硬编码。上面的校验和是通过将字符串“secret”前置到分数“500”前，并通过md5sum运行来创建的。

Although this system will prevent a user from posting arbitrary scores, it does not prevent a "replay attack", where a user reposts a previously calculated score and hash combination. In the example above, a score of 500 would always produce the same hash string. Some of this risk can be mitigated by incorporating more information (such as a username, timestamp, or IP address) in the string which is to be hashed. Although this will not prevent the replay of data, it will insure that a set of data is only valid for a single user at a single time.

为了防止任何重放攻击的发生，必须创建某种类型的挑战-响应系统，例如:

The flash game ("the client") performs an HTTP GET of http://example.com/highscores.php with no parameters. This page returns two values: a randomly generated salt value, and a cryptographic hash of that salt value combined with the shared secret. This salt value should be stored in a local database of pending queries, and should have a timestamp associated with it so that it can "expire" after perhaps one minute. The flash game combines the salt value with the shared secret and calculates a hash to verify that this matches the one provided by the server. This step is necessary to prevent tampering with salt values by users, as it verifies that the salt value was actually generated by the server. The flash game combines the salt value with the shared secret, high score value, and any other relevant information (nickname, ip, timestamp), and calculates a hash. It then sends this information back to the PHP backend via HTTP GET or POST, along with the salt value, high score, and other information. The server combines the information received in the same way as on the client, and calculates a hash to verify that this matches the one provided by the client. It then also verifies that the salt value is still valid as listed in the pending query list. If both these conditions are true, it writes the high score to the high score table and returns a signed "success" message to the client. It also removes the salt value from the pending query list.

请记住，如果用户可以访问共享秘密，则上述任何技术的安全性都会受到损害

作为一种替代方法，可以通过强制客户端通过HTTPS与服务器通信，并确保客户端预先配置为只信任由您单独有权访问的特定证书颁发机构签署的证书来避免这种来回。