...我已经在这里读过一些讨论过各种方法的线程，并且只是在我们提出的建议解决方案上寻找一些反馈。在其中一条线索中发布了评论，推荐一个公钥/私钥，听起来很棒，这就是我们在想的...关于（半）保护Flash/PHP游戏高分的建议
客户端 - 1.密钥存储在Flash swf中，使用3rd派对工具。 2.高分数与高得分值沿着散列（EX：MD5（“ourSecretKey” + 200）） 3。该值是通过AMF发送到PHP脚本在服务器上，与高得分沿（200 ）
服务器端 - 1.服务器接收数据并散列传递的高分（200）密钥（存储在服务器和Flash中的'ourSecretKey'），并检查传递的哈希值是允许输入高分的匹配项，否则为失败。
我知道这不是一个万无一失的解决方案，但这是可以接受的吗？我的意思是，这是一个简单的在线Flash游戏的高分数形式足够的安全性？思考？
预先感谢您！
对于一个荒谬的短值（即：值为<的64个字符），由于彩虹表攻击，MD5作为散列变得无效，并且由于您发送的值将通过线路共享，所有他们必须做的是蛮力共享的秘密（他们有一个已知的产品一起工作）
这样，那不是公钥私钥。它巧妙地共享秘密。
而且，记住这个共享的秘密将是您的Flash文件发送给用户，这些天，而轻易地拆卸，那么你的“秘密”已经不是什么秘密了。
你想与适当的加密签名，其中一个新的符号键被分配给从服务器每一场比赛，并多次得分更质询 - 响应机制，不能用相同的符号键提交。 （用于额外保护;））
但是，你仍然有在您没有办法阻止实际的评分系统被篡改的问题。有人足够聪明，只需对您的SWF对象进行反向工程，并注入新的代码即可将分数设置为其所选值。
您的问题的答案是，这取决于。这主要取决于游戏的估计流行度。
从安全角度来看，您的解决方案是关于作为明文发送高分一样安全。你在这里所做的就是默默无闻的安全，根据你听的人的情况，在某些情况下可能会有好处。在这种情况下，可能是乔的普通用户不可能自己破解它。对于任何拥有l33t h4xxor技能的人，你都可以用明文形式发送。如果你想要阻止乔，那么这可能就足够了，至少在某人为乔创建一个假客户端的情况下（这取决于你的游戏的流行度可能需要几天时间才能完成）或者如果是哇））。
更好的解决方案是@Kent Fredric提供的解决方案。然而，正如它表示，它不能解决有人创建假客户端的问题。解决方案可能是这样的：
这将保证两两件事：
但是这个方案仍然存在一个严重的缺陷。没有办法知道游戏实际上是在玩游戏。如果客户受到威胁，该列表可能只是发送给服务器的“完美游戏”的预制件。直接篡改评分系统是不可能的，但只要有足够的努力，人们很可能会创建一个包含“完美游戏”的动作列表。
然而，它比在肯特弗雷德里克的帖子中使用解决方案提供了更强的保证。解决整个问题意味着你必须以某种方式验证客户端。这是非常困难的，因为这样做的大多数方法都很容易规避。
最后，我只是对你选择的哈希算法发表评论：对于那些仍然生活在九十年代的人来说，MD5是一个很棒的哈希算法。对于我们其他人，我推荐SHA-2或至少SHA-1。
这个方案可以通过让服务器决定并发送每个游戏的随机种子来进一步改进。例如。客户端告诉服务器它想玩。服务器说，好吧，玩种子nn发起的游戏。然后当客户想要上传高分时，服务器检查高分实际上是否用于游戏nn。即使这个计划可以被黑客入侵，但是整个游戏都需要进行修改。工程。并重建。哪些可以完成（并且已经用于一些使用该方案的流行游戏）。 – 2012-11-20 09:01:01
是的，当然，客户端可能仍然蛮力排列动作列表来找到一个产生理想分数的序列，但是你至少提高了从O（1）到某个东西产生假分数所需的计算复杂度更多的O（n^3），不得不蛮力排列找到一个合适的分数，至少应该让真正的业余爱好者退出，而他们会采取相反的措施。 – 2012-12-02 16:42:41
块引用 最后，我只对你所选择的哈希算法的评论：MD5是为那些仍然生活在上个世纪九十年代很大的哈希算法。对于我们其他人，我推荐SHA-2或至少SHA-1。
呸，我知道我应该提到SHA代替:)
如果我不使用像一个swf加密应用程序加密，SWF代码中不会，至少使相当多的困难获取存储在Flash中的密钥？我认为如果没有这个密钥（或者至少不容易），找出用于生成发送到服务器的散列的内容将是一个巨大的痛苦。
像这样的东西是什么，我在想：SWF Encrypt
再次感谢大家对这些问题的答案，这是令人惊讶的帮助。哦，这只是一个简单的Flash游戏，由客户发送给客户，有趣的事情可以在假期工作。
如果您的游戏分布有限，且没有真正的金钱/奖金参与玩家获胜，您的原始方案可能就足够了。
使用SWF Encrypt可能会使提取密钥更困难一些，即使在更高级的系统中使用它也可能是一个很好的工具。但是如果你有一个真正的公钥/私钥方案（例如RSA），这实际上是一个有争议的问题，因为公钥不是秘密，它不应该是秘密。仍然为了防止大多数人编辑代码并篡改评分系统，SWF Encrypt可能是一个足够好的选择。
只是为了让你多一点偏执我写了下面还有：
与SWF加密问题，与大多数其他类似的工具，是它仍然必须能够执行脚本在（可能受损）的机器上。所以所有信息必须在所述机器上可用。与经典密码学的使用相比，发送消息：
当您发送加密消息时，您通常会信任源和目标，因此这两者都有解密消息的密钥。你不相信的是信使，或者至少不是你的敌人不会拦截信使。所以信使没有钥匙，你的信息是安全的。
您的问题在于，您相信目的地（您）而不是来源（客户），反之亦然。尽管如此，您还是需要信息来源能够加密信息，因为您更信任信使。因此，源需要具有所有信息来加密和解密消息才能正常工作。你的问题是你看不到“好”源和“坏”源之间的区别。
我的意思是说，由于代码必须仍然可以在客户端上运行，所以这样做的信息必须完全可用，尽管可能以模糊的形式存在。黑客可以创建自己的ActionScript编译器，将混淆的ActionScript代码转换为可读的并进行适当更改。困难但绝对可行。
然而，如果你的发行量有限，而且没有真正的赢钱，那么这种复杂的攻击水平很可能不会成为你的问题。
对来源不可信的基本原则有很好的评论。 – noio 2012-11-11 13:55:17
肯特提到，我没有看到使用该解决方案的任何优势。作为客户端，我可以请求服务器端创建密钥。好的，我不能多次使用它，但我不必......每当我需要它时，我都会请求它。
当然，这只会增加复杂性。但是，“共享密钥”是一种“发现一次，提供数百万次”的方法，而每键1键则至少让你依赖分配密钥的服务器，并且可能会限制分配这些密钥键。 但是Andreas的基于序列复杂性的安全性可能会使复杂性太难以使其值得扭转。 – 2012-12-02 16:49:45
哇
漂亮的硬解8）。
我实现了这样的系统一次。虽然它没有为每场比赛的工作...
你应该在服务器上重放游戏。当用户玩 - 你存储“状态改变”，然后简单地以某种“重放”模式给你游戏。
有一个且只有一个100％的加密分数的工作方式：记录重播。
但不只是任何重播，理想情况下，您应该只记录用户按键和它们之间的空间。这样，即使有人篡改了源或RAM动态，服务器上播放的重播也会发现问题。
不幸的是，这种解决方案需要大量的工作才能实现。为了简单起见，您可以手动验证所有分数（或最佳分数），并且您很高兴。尽管如此，你仍然需要避免一些事情：
可能还有更多。
然而，这种防御是牢不可破的。代码需要时间：D。
请注意，这篇文章有几年在回来，事情总是发生。现在认为MD5 *已完全破碎。 – 2012-11-20 08:50:46