java - 在 ServletContext 中临时保存用户密码的想法有什么本质上的错误吗？
问题描述
这是前提，我不允许在这个网站上使用 JavaScript 或 Cookies。
但是，对于需要密码至少 15-30 分钟的每项基本任务，我不希望向用户询问密码。
我也不喜欢将密码保存到临时文件中，以防程序死机并且无法按计划删除它。
所以我的计划是在第一次联系时，为用户分配一个唯一的随机生成的安全 id/hash，并将其附加到他们生成的 HTML 中。服务器端将他们的密码与 ServletContext 中的 id 匹配。这样，对于他们所有传入的请求，我可以匹配它们而无需在所有类中要求密码。
此外，我将确保在 15-30 分钟到期时自动从 ServletContext 中删除他们的信息。
到目前为止，在我看来，这种方法既避免了 JS 又避免了 Cookie，也避免了程序死机时存在风险的所有外部存储方法。是的，ServletContext 应该是全局的，但是如果没有它们唯一的临时 id/hash，任何人都无法模仿它们。
我问这个问题是因为我找不到其他人问同样的问题，所以我需要确保这种方法没有任何问题。
解决方案
鉴于以下限制：
- 不允许使用 cookie。
- 不允许 JS。
- 在客户端缓存凭据不是一种选择。
乍一看，提议的方法似乎还可以。但是，我建议您遵循以下准则：
- 确保重放攻击是不可能的。由于您无法在客户端对请求进行散列和签名，因此在后端经常（最好是每次请求）使令牌无效和刷新。
- CSRF 应对措施应该到位。
- 应该强制执行 SSL。