java - 在 ServletContext 中临时保存用户密码的想法有什么本质上的错误吗？

Question

这里的前提是，我不允许在这个网站上使用JavaScript或Cookies。

但是，我不想在每项至少需要密码 15-30 分钟的基本任务中询问用户密码。

我也不喜欢将密码保存到临时文件中，以防程序死掉并且无法按计划删除它。

所以我的计划是在第一次联系时，为用户分配一个唯一的随机生成的安全 ID/哈希，并将其附加到生成的 HTML 中。服务器端将其密码与 ServletContext 内的 ID 进行匹配。这样，对于他们所有传入的请求，我可以匹配它们，而无需在所有类别中询问密码。

此外，我将确保在 15-30 分钟到期时自动从 ServletContext 中删除它们的信息。

到目前为止，在我看来，这种方法避免了 JS 和 Cookie，也避免了程序终止时面临风险的所有外部存储方法。是的，ServletContext 应该是全局的，但是如果没有它们唯一的临时 id/hash，没有人能够模拟它们。

我问这个问题是因为我找不到其他人问同样的问题，所以我需要确保这个方法没有任何问题。

Answer 1

考虑到以下限制:

1. 不允许使用 cookie。
2. 不允许使用 JS。
3. 不能在客户端缓存凭据。

乍一看，所提出的方法似乎没问题。不过，我建议您遵循以下准则:

1. 确保不可能发生重放攻击。由于您无法在客户端对请求进行哈希处理和签名，因此请在后端频繁地使 token 失效并刷新(最好是在每个请求时)。
2. 应采取 CSRF 对策。
3. 应强制执行 SSL。