我已经看到尝试过这种方法并最终取消它的实现，因为是的，它可能会导致资源问题和跨 Web 场的竞争条件。一开始这听起来是个好主意，但如果重新生成过程的密码密集度太高，也会使您的应用程序更容易受到拒绝服务攻击。答案是定期预生成会话 ID 并保持缓存可用，但是您必须安全地管理缓存。

保护会话 ID 变量的一些更常见的解决方案是

• 使用 SSL
• 仅在通过 SSL 成功登录后生成经过身份验证的会话 ID ，否则您将容易受到会话固定
• 生成加密随机且不可猜测的令牌
• 经常使会话 ID 过期
• 正确过期，然后在服务器端注销
• 将会话 ID cookie 标记为 HttpOnly 和“安全”

我想这取决于你将如何实现这整个事情，但很可能你会遇到许多跟踪不断变化的会话 id 的运行时问题。

这会有帮助吗？并不真地。您可以欺骗 REMOTE_ADDR，并且在会话 id 更改之前捕获它非常简单：在用户发出另一个请求之前捕获并使用它。

更好的想法是加密 cookie 值，仅通过 HTTPS 连接，将 cookie 生命周期设置为非常短/将会话生命周期设置为非常短，将 cookie 设置为 HttpOnly（无法通过 JavaScript 访问——仅部分较新的浏览器），最后，使用框架会话管理——不要自己动手。:)

你应该确保你的会话过期并且令牌当然是可靠的并且是随机生成的。

但是，从所有这些答案中，我认为最强的一点是使用 SSL - 但对于整个会话。

即使您通过 SSL 登录，并从那时起使用普通的 http，从每个后续请求中重新生成会话，并完成上述所有好事，也确实无法保证用户的会话不会以某种方式被劫持。您确实需要确保整个会话的传输可以防止窃听和劫持——这是 SSL 设计的。

当涉及到 NATed 防火墙时，远程地址的使用也没有实际意义。

如果您需要进一步确保特定客户端的机器是唯一可以登录的机器，您可以颁发客户端证书，用户将其加载到他们的浏览器中，服务器将在 SSL 协商期间请求此.

我在常见用法中看到的最好的方法是在安全登录后重新生成会话标识符，并将标识符与客户端机器相关联。应用程序的安全包装器检查并发登录（在旧登录完成并且 ID 过期之前不允许新登录）在浏览器关闭或注销时使 ID 过期，并且过期时间也很短（10 分钟）

结合其他安全功能，它适用于该目的（在线消费者银行应用程序），而不会使系统过载。