security - 安全性:此身份验证/加密方案有多脆弱？

Question

我有一个客户端服务器游戏，客户端连接到服务器并在游戏过程中保持连接状态（大约5-60分钟）。

我希望新客户端能够安全地注册，并允许现有客户端进行身份验证而不必担心会暴露登录凭据。

事实是，出于性能方面的考虑，最好在游戏会话中坚持使用简单廉价的加密技术（例如RC4），但是对称密钥并不容易确保注册过程的安全。

由于我还是想保留一个单独的登录服务器，因此我的想法是这样的：


客户端使用凭据（或注册信息）向登录服务器发送HTTPS请求
登录服务器收集用户信息，并生成一个临时的RC4会话加密密钥
用户信息+ RC4会话+时间戳+摘要（我可以依靠两个服务器在时间上进行同步）以及秘密对称密钥，该密钥在游戏服务器和登录服务器之间共享。
发送给游戏服务器的打包数据+ RC4会话加密密钥+ IP地址作为对客户端的HTTPS请求的答复。
客户端打开与游戏服务器的连接，发送初始的未加密问候消息，并将加密的用户信息作为有效内容。
游戏服务器解压缩（3）中打包的数据。现在，它知道用户以及应该使用的RC4加密密钥。
如果时间戳指示登录凭据已过期，则会向客户端返回错误（客户端将检索新信息）。如果不能用摘要验证解密的用户数据，则返回另一个错误。
如果一切正常，则服务器发送未加密的LOGIN_OK，并且RC4加密的通信开始。


可能的安全问题：


游戏服务器100％信任已解密的用户信息。这使得服务器完全解耦，这很好，但是如果密钥被泄露，用户可能会完全伪造其用户信息。通过旋转这些键可以在某种程度上缓解这种情况，以便每天或每个月都有一个新的键。游戏服务器和登录服务器都可以从管理其密钥的第三台服务器获得此信息。这可能是过大的杀伤力，因为：a）如果服务器上暴露了源代码，则可以使用新密钥重新启动它们； b）足够好的密钥+加密应使蛮力攻击难以进行（算法建议） ？）
RC4不是最安全的算法，但是我确保丢弃前512个字节左右，并且每个密钥仅在有限的时间内有效，例如24小时
从我看来，中间人似乎并不敏感：SSL保护RC4会话密钥，在（5）中，发送给游戏服务器的RC4会话密钥也已加密。可能的就是DoS并导致用户再次请求密钥。如果（2）中的数据一直缓存到过期，则不应创建新的数据包。
可以通过向密钥添加随机位来改进（3）中的加密。这些随机位与加密的数据包一起发送，并在（5）中呈现给游戏服务器。在（6）中，游戏服务器将这些随机位添加到他的密钥中，并使用结果解密数据。这样，攻击者就看不到打包数据何时更改。


我在这里有没有忽略的漏洞？

创建的有效负载的摘要：


客户端登录凭证（受SSL保护），发送到登录服务器
用户信息+时间戳+游戏服务器临时会话密钥+使用与游戏服务器共享的秘密密钥由登录服务器加密的摘要，提供给客户端，客户端无需修改即可将其传递给游戏服务器。之所以可以防暴躁，是因为：a）客户端不知道密钥b）有时间戳，以避免重新发送相同的数据c）摘要以验证内容是否正确加密
登录服务器发送给客户端的临时游戏服务器会话密钥以及加密的有效负载。受SSL保护。
客户端游戏服务器登录数据包，由登录服务器收到的加密数据包组成。


加密密钥摘要：


临时游戏服务器会话密钥：由登录服务器随机生成，用于加密的游戏服务器<->客户端通信。由登录服务器生成，提供给客户端和游戏服务器。
秘密用户信息加密密钥。在游戏服务器和登录服务器之间共享，用于将用户信息以客户端作为Messenger传递到游戏服务器。客户没有此密钥。

Answer 1

首先，我不会使用RC4。既有速度更快又更安全的流密码，因此，如果您同时控制客户端和服务器，则可能会比RC4更好。仅丢弃512个字节可能不足以应付Fluhrer，Mantin和Shamir攻击，但是即使您丢弃更多字节，也有Klein的攻击等。我不知道是否值得这样做。

其次，确保您生成的密钥是随机的。我知道它似乎很明显，但是例如：http://www.debian.org/security/2008/dsa-1571

但是真正的问题是这部分：“游戏服务器100％信任解密的用户信息。这使得服务器完全解耦，这很好，但是如果密钥被泄露，用户就可以完全伪造用户信息。”

您必须假设用户知道密钥。他的游戏客户端必须知道密钥，以便它可以与服务器通信。如果用户可以使用自己的真实数据通过ssl登录，获取流密码的密钥，然后将其所需的任何信息发送到游戏服务器，那么攻击者所需要做的就是获得一个帐户并执行其所需的任何操作。

更改密钥的频率无关紧要，因为每次更改密钥时，您仍然必须将其提供给客户端，因此您最好在每个字节之后进行更改，而在这里仍然无关紧要。

这比所使用的密码或密钥生成更为重要，因为如果有人获得密钥，就不会有人用暴力破解密钥。

您不应该信任客户。您应该将客户端数据存储在服务器端，并与密钥进行匹配，或者对数据进行签名并进行验证或使用HMAC等。因为如果游戏服务器100％信任用户信息，那么您很快就会遇到问题。几乎没有办法解决它。