安全性:这种身份验证/加密方案有多脆弱？
我有一个客户端服务器游戏，客户端连接到服务器并在游戏期间保持连接(大约5-60分钟)。
我希望新客户端能够安全注册，并允许现有客户端进行身份验证，而不必担心登录凭据被公开。
问题是，出于性能原因，最好在游戏会话中坚持使用简单而廉价的加密(如RC4 )，但是对称密钥并不能使注册过程变得容易。
由于我希望保留一个单独的登录服务器，所以我的想法如下：
information)
- The客户端通过凭证(或注册登录服务器收集用户信息)向登录服务器发送HTTPS请求，并生成临时RC4会话加密密钥
- 用户信息+ RC4会话+时间戳+摘要(我可以依靠这两台服务器实现时间同步)，并在游戏服务器和登录服务器之间共享一个秘密对称密钥。
- 将打包的数据+ RC4会话加密密钥+ ip地址发送到游戏服务器，作为对HTTPS请求的答复发送给客户端。
- 客户端打开到游戏服务器的连接，以加密的用户信息作为有效负载发送初始未加密的hello消息。游戏服务器
- 解压缩打包在(3)中的数据。它现在知道用户和它应该使用的RC4加密密钥。
- 如果时间戳指示登录凭据已过期，则会向客户端返回一个错误(然后客户端将检索新信息)。如果无法用摘要验证解密的用户数据，则返回不同的错误。
- 如果一切正常，服务器发送未加密的LOGIN_OK，RC4加密通信启动。
可能引起的安全关切：
游戏服务器
- 100%信任它解密的用户信息。这使得服务器完全解耦，这很好，但如果密钥被泄露，用户可以完全伪造他们的用户信息。可以通过旋转这些键来稍微减轻这种情况，这样每天或每个月都有一个新的键。游戏服务器和登录服务器都可以从管理其密钥的第三台服务器上获得此信息。这可能是过火了，因为: a)在服务器上暴露源代码的情况下，可以用新的密钥b重新启动它们)，一个足够好的密钥+加密应该会使暴力攻击变得困难(关于algorithm?)
- RC4的建议不是最安全的算法，但我确保丢弃最初的512个字节左右，每个密钥只在有限的时间内有效，例如24小时。
- 似乎对人不敏感-在我可以看到的中间部分: SSL保护RC4会话密钥，在(5)发送到游戏服务器的RC4会话密钥也是加密的。所有可能的是DoS，并导致用户再次请求一个密钥。如果(2)中的数据被缓存到过期，这就不应该创建新的数据包。
- (3)中的加密可以通过向密钥中添加随机位来改进。这些随机比特与加密的分组一起发送，并在(5)中呈现给游戏服务器。在(6)中，游戏服务器将这些随机比特添加到他的密钥中，并使用结果解密数据。这样，攻击者就无法看到打包的数据何时发生变化。
我在这里有什么弱点吗？
创建的有效载荷摘要：
- 客户端登录-凭据(受SSL保护)，发送到登录服务器
- 用户信息+时间戳+临时游戏服务器会话密钥+使用与游戏服务器共享的秘密密钥加密的暂存游戏服务器会话密钥+摘要，给客户端，客户端在不修改的情况下将其传递给游戏服务器。因为：( a)客户端不知道密钥b)具有时间戳以避免重发相同的数据( c)摘要以验证内容是加密的correctly
- temporary游戏服务器会话密钥由登录服务器发送给客户端以及加密的有效载荷。受SSL.
.
- 客户端游戏服务器登录包的保护，由登录服务器接收的加密数据包组成.
加密密钥概述：
- 临时游戏服务器会话密钥:由登录服务器随机生成，用于加密游戏服务器<->客户端通信。由登录服务器生成，给客户端和游戏server.
- Secret用户信息加密密钥。在游戏服务器和登录服务器之间共享，使用客户端作为信使将用户信息传递给游戏服务器。客户端不拥有此密钥。
回答 5
Stack Overflow用户
发布于 2011-02-25 11:54:19
最后，我还在sci.crypt上发布了文章，我将尝试在下面总结建议的更改(据我理解)，以防引起兴趣。
步骤1:客户端向具有凭据的登录服务器发送HTTPS请求
假设凭据采用登录令牌的形式，还添加一个自分配的唯一id。
步骤3:用户信息+ RC4会话+时间戳+摘要
使用确保完整性的加密算法，而不是显式使用摘要。例如AES-GCM或AES-CCM。在步骤1中添加额外的id字段，并将ip添加到游戏服务器。
步骤4:将打包的数据+ RC4会话加密密钥+ ip地址发送到游戏服务器。
将时间戳给客户端将允许客户端知道会话何时过期。这避免了使用过期凭据与游戏服务器的不必要连接。
步骤5:客户端打开到游戏服务器的连接，发送初始未加密的hello消息，其中包含加密的用户信息作为有效负载.
将步骤1中未加密的自分配id添加到有效负载。
步骤6:游戏服务器解压缩打包在(3)中的数据。它现在知道用户和它应该使用的RC4加密密钥。
游戏服务器将自己的ip与加密的ip相匹配，并将加密的id与客户端提供的id匹配。第一种方法防止用户使用相同的凭据转到另一台服务器。
步骤8:如果检查是否正常，服务器将发送未加密的LOGIN_OK，RC4加密通信将启动.
此时，游戏服务器无法确定客户端的身份。使用会话密钥并使用AES-GCM/CCM加密当前+严格增加会话id +登录成功状态，并将其发送给客户端。
客户端解密并检查登录成功状态。如果这是真的，那么客户端就知道游戏服务器知道会话密钥(GCM/CCM验证数据包没有被篡改)。客户端返回sid + nonce。
服务器验证sid + nonce与发送的值相同。
最后，客户机和服务器通过散列来创建新的会话密钥，使用sid + nonce + salt来创建相应通信的密钥，以防止可能的重放攻击。
关于RC4
RC4中存在漏洞，但由于相当激进的密钥重新安排，该方案可能已经足够了。然而，有一些更安全和更快的现代密码，如斯诺2.0或Trivium。
Stack Overflow用户
发布于 2011-02-16 12:45:22
首先，我不会使用RC4。这里有更快、更安全的流密码，所以如果您同时控制客户端和服务器，那么您可能会比RC4做得更好。对于Fluhrer，Mantin和Shamir攻击来说，丢弃512字节可能不够，但是即使你丢弃更多的字节，也有Klein的攻击等等。我不知道这是否值得。
第二，确保生成的密钥是随机的。我知道这似乎很明显，但举个例子，参见：http://www.debian.org/security/2008/dsa-1571
但真正的问题是：“游戏服务器100%信任它解密的用户信息。这使得服务器完全解耦--这很好，但如果密钥被泄露，用户可以完全伪造用户信息。”
您必须假设用户知道密钥。他的游戏客户端必须知道密钥，这样它才能与服务器通信。如果用户可以使用他的真实数据通过ssl登录，获取流密码的密钥，然后向游戏服务器发送他想要的任何信息，那么攻击者所要做的就是得到一个帐户，然后做他想做的任何事情。
您更改键的频率并不重要，因为每次更改键时，您仍然必须将其交给客户端，所以您最好在每个字节之后更改它，但在这里仍然不重要。
这比密码或密钥生成更重要，因为没有人会用暴力强迫密钥，如果他只是得到它。
你不应该相信客户。您应该将客户端的数据存储在服务器端，并将其与密钥匹配，或者对数据进行签名、验证或使用HMAC等，因为如果游戏服务器100%信任用户信息，那么您迟早会遇到问题。几乎没有办法绕过它。
Stack Overflow用户
发布于 2011-02-17 03:26:25
听起来你在尝试重新发明SSL。为什么不给每个客户端颁发一个证书(由您自己的根授权机构签名)，并让它们通过SSL连接到游戏服务器，并进行相互认证？
https://stackoverflow.com/questions/5015134
复制相似问题
腾讯云开发者
