我正在写一个多人游戏。我有一个处理一切的中央服务器。对于数据交换，我使用 HTTPS 协议。因为这是一款游戏，所以我不能使用 RSA 等计算成本高昂的系统进行数据传输。
登录，
seed。seed。access_key登录成功的响应要发送需要登录的请求，
access_key和生成的哈希seed以及请求数据。access_key和 生成的哈希是否seed正确。如果是，access_key则从旧的生成新的，处理请求数据，服务器将新的access_key与请求的响应一起返回。在任何时候，如果客户端的 IP 更改或access_key发送无效，会话将自动终止。
这种方法有多安全？我能做些什么来改善它？
首先，加密很难，你不应该创建自己的.
您的登录似乎受到了散列传递漏洞的影响。攻击者无需破解哈希即可登录，他们只需传递哈希即可登录。这首先破坏了对密码进行哈希处理的目的。
不建议使用 sha512 存储密码，因为它太快了。改用bcrypt 之类的东西。
你说RSA太贵了。但通常，RSA 仅用于交换密钥，然后与更便宜的私钥密码系统一起使用。
正如您阐明的那样，您确实使用了 HTTPS，应该注意您确实已经使用了 RSA。HTTPS 使用 RSA 或 diffie hellman 进行密钥交换，并使用一些块或流密码进行实际数据加密。
当您使用 HTTPS 时，您已经拥有数据机密性和完整性（以及服务器身份验证和可选的客户端身份验证），无需在应用程序级别进行额外加密。
你的计划似乎并没有真正起到任何作用。您已经可以避免通过 HTTPS 进行窃听和数据篡改（而且您的方案无论如何也不会阻止它）。
因此，您的方案似乎与数据交换无关，而与身份验证有关。
通常，身份验证是这样处理的：
登录：
其他要求：
您的方法类似，但确实引入了 pass the hash 漏洞，并包含一个种子，这似乎是不必要的，因此只会使方案复杂化。它还会在每个请求上重新生成会话 ID，这并不是真正需要的，而且似乎只会造成不必要的开销。
...客户端向服务器发送带有用户名、哈希和种子的“登录”请求。
由于种子是由客户端创建的，因此种子和哈希的组合有效地形成了一个密码等价物，可以一次又一次地重播。您可能正在尝试在这里实现类似于Digest Authentication的东西。但是对于摘要式身份验证，nonce（即您的“种子”）由服务器而不是由客户端确定，因此可以安全地抵御重放攻击。
除此之外：您已经在使用 HTTPS 来保护流量免受嗅探和修改。为什么要在其之上构建另一个安全机制？摘要式身份验证通常用于未加密的连接，并且存在您需要在服务器上明确（或等效）密码的问题。如果连接已经受到保护以防嗅探，则不需要对密码进行额外保护，并且可以明文发送。这样做的好处是您可以将密码存储为服务器上的不可逆哈希。