建议（半）保证Flash / PHP游戏中的高分

Question

...我在这里已经阅读了一些讨论了各种方法的线程，并且只是在寻找对我们提出的建议解决方案的一些反馈。在其中一个帖子中发布了一条评论，推荐了一个听起来很棒的公钥/私钥，这就是我们的想法......

客户端 - 1.密钥存储在Flash swf内部，使用第三方工具加密。 2.高分与高分值一起散列（EX：md5（'ourSecretKey'+ 200）） 3.此值通过AMF发送到服务器上的PHP脚本以及高分（200）

服务器端 - 1.服务器接收数据并哈希传递的高分（200）+密钥（存储在服务器以及Flash中的'ourSecretKey'）并检查传递的哈希值，如果值匹配则允许高分输入，否则失败。

我知道这不是一个万无一失的解决方案，但这是否可以接受？我的意思是，对于一个简单的在线Flash游戏，这是否足够安全？想法？

提前谢谢！

Answer 1

对于一个荒谬的短值（即：值<64个字符），由于彩虹表攻击，MD5作为哈希变得无效，并且由于您发送的值将通过线路共享，所以他们只需做是强制共享的秘密（他们有一个已知的产品可以使用）

因此，那不是公钥私钥。它的共同秘密。

此外，请记住，这个共享秘密将存储在您发送给用户的Flash文件中，这些日子被轻易拆解，然后您的“秘密”不再是秘密。

您需要一个具有正确加密签名的更具挑战性的响应机制，其中为服务器中的每个游戏分配新的签名密钥，并且不能使用相同的签名密钥提交多个分数。 （为了额外的保护;））

1. 用户开始游戏。请求签名密钥。 （符号密钥是由他们无法访问的另一个密钥生成的。）
2. 分数用签名密钥签名，然后发送
3. 您使用发送的密钥验证标志的值。
4. 您放弃发送给他们的签名密钥。

但是，仍然存在无法阻止实际评分系统被篡改的问题。足够聪明的人可以对SWF对象进行反向工程，并注入新的代码，只需将分数设置为所选值即可。

Answer 2

你的问题的答案是，这取决于。这主要取决于游戏的估计受欢迎程度。

从安全角度来看，您的解决方案与以明文形式发送高分数一样安全。你在这里做的事情被默默无闻称为安全，根据你所听到的人，在某些情况下可能会有其好处。在这种情况下，普通用户可能不会自己破解它。对于任何拥有l33t h4xxor技能的人来说，你也可以用明文发送。如果你想要的只是停止乔，那么这可能已经足够了，至少在有人创建了一个假的客户端供乔下载（这取决于你的游戏的受欢迎程度可能需要几天甚至更长的时间（或者更快，如果它是WOW））。

更好的解决方案是@Kent Fredric给出的解决方案。然而，因为它说它没有解决有人创建假客户端的问题。解决方案可能是这样的：

1. 让玩家可以执行身份证的每个动作。
2. 将玩家执行的每项操作存储在ID列表中。
3. 当游戏超过散列分数时，操作列表并使用从服务器接收的公钥对其进行加密。 （有关详细信息，请参见Kent Fredric的帖子）
4. 将加密的哈希（通常称为数字签名）与分数和一起发送到服务器。
5. 让服务器根据列表中的操作“玩”游戏。
6. 确认已达到相同的分数。
7. 验证数字签名是否正确。
8. 更新服务器高分榜。

这将保证两件事：

1. 得分来自正确的客户。
2. 关于比赛的得分是正确的。

但这个计划还有一个严重的缺陷。没有办法知道游戏实际上是在玩游戏。如果客户端被泄露，该列表可能只是一个发送到服务器的“完美游戏”的预制件。直接篡改评分系统是不可能的，但是如果付出足够的努力，很可能会创建一个包含“完美游戏”的动作列表。

然而，它比肯特弗雷德里克的帖子中使用解决方案提供了更强有力的保证。解决整个问题意味着您必须以某种方式验证客户端。这是非常困难的，因为大多数这样做的方法很容易被规避。

最后，我只是评论你选择的哈希算法：对于那些仍然生活在九十年代的人来说，MD5是一个很好的哈希算法。对于我们其他人，我建议使用SHA-2或至少SHA-1。

Answer 3

如果您的游戏分布有限且玩家无法获得真正的金钱/赏金，那么您的原始计划可能就足够了。

使用SWF加密可能会使提取密钥变得更加困难，并且它甚至可以在更高级的系统中使用。但是，如果你有一个真正的公钥/私钥方案（例如RSA），它真的是一个没有实际意义的点，因为公钥不是秘密，它不应该是。为了防止大多数人编辑代码并篡改评分系统，SWF加密可能是一个不错的选择。

---

为了让你更偏执，我还写了以下内容：

与大多数其他类似工具一样，SWF加密的问题在于仍然可以在（可能受到危害的）计算机上执行脚本。因此，所有信息必须在所述机器上可用。将其与经典的密码术相比较，发送消息：

发送加密邮件时，通常会信任源和目标，因此这两者都有解密邮件的密钥。你不信任的是快递，或者至少不是你的敌人不会拦截信使。因此，快递员没有密钥，您的信息也是安全的。

您的问题是，在您的情况下，您信任目的地（您）而不是信任源（客户端），反之亦然。您仍然需要源可以加密消息，因为您更信任信使。因此，源需要拥有所有信息来加密和解密消息才能运行。你的问题是你无法看到“好”来源和“坏”来源之间的区别。

我的意思是，由于代码必须仍然可以在客户端上运行，因此必须完全可以获得这样做的信息，尽管可能是模糊的形式。例如，黑客可以创建自己的ActionScript编译器，将混淆的ActionScript代码转换为可读的内容并进行适当的更改。困难但绝对可行。

然而，如果你的发行量有限且无法获得真正的赏金，那么这种复杂的攻击很可能对你来说不是问题。

Answer 4

  

块引用   最后我只是评论你选择的哈希算法：对于那些仍然生活在九十年代的人来说，MD5是一个很好的哈希算法。对于我们其他人，我建议使用SHA-2或至少SHA-1。

我知道我应该提到SHA而不是：）

如果我确实使用类似swf加密器应用程序来加密swf代码那么至少会让得到存储在Flash中的密钥变得更加困难吗？我认为如果没有那个密钥（或者至少没有轻易搞定），找出用于生成发送到服务器的哈希的内容将是一件巨大的痛苦。

我想到的是这样的事情：SWF Encrypt

再次感谢大家的回答，这非常有帮助。哦，这只是客户向客户发送的一个简单的Flash游戏，在假期工作时间有趣。

Answer 5

肯特提到，我认为使用该解决方案没有任何优势。 作为客户端，我可以请求服务器端创建密钥。好吧，我不能使用它超过一次，但我没有...每次我需要一个我只是要求它。

1. 所以我要求钥匙。
2. 制作自己的高分
3. 用钥匙哈希高分。
4. 将高分发送给服务器
5. 服务器使用提交的密钥来获得高分。

Answer 6

有一种且只有一种100％的加密分数的工作方式：录制重播 但不仅仅是任何重播，理想情况下你应该只记录用户按键和它们之间的空格。这样，即使有人篡改了源或动态地使用RAM，服务器上播放的重放也会发现问题 遗憾的是，这种解决方案需要大量的工作才能实现。为简单起见，您只需手动验证所有分数（或最佳分数），您就会感到高兴。不过你还是要避免一些事情：

• 默认随机生成器，您需要Seeded生成器，它始终为给定的种子提供相同的随机数;
• 没有delta计时，抱歉;
• 自定义三角函数（我不是100％肯定，我听说过他们可以在不同的计算机上给出稍微不同的结果）;

可能更多。
然而，这种防御完全是牢不可破的。并且需要时间来编码：D。

Answer 7

哇

非常难的解决方案8）。

我曾经实施过这样的系统。虽然它不会为每场比赛而努力......

您应该在服务器上重播游戏。用户玩游戏时 - 存储“状态变化”，然后以某种“重放”模式将其提供给游戏。