在ServletContext中临时保存用户密码的想法有天生的错误吗？

Question

在此前提下，不允许我在此网站上使用JavaScript或Cookies。

但是，我不希望在至少需要15-30分钟的密码的每项基本任务中都要求用户提供密码。

我也不喜欢将密码保存到临时文件中的想法，以防程序死机而无法按计划擦除它。

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

我还将确保在15到30分钟过期后自动从ServletContext中删除其信息。

到目前为止，在我看来，这种方法既避免了JS和Cookies，也避免了程序终止时所有处于危险之中的外部存储方法。是的，ServletContext应该是全局的，但是如果没有它们唯一的临时id /哈希，就没有人能够模拟它们。

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

Answer 1

鉴于以下限制：

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

乍看之下，建议的方法似乎还可以。但是，我建议您遵循以下准则：

1. 确保无法进行重放攻击。由于您无法在客户端对请求进行哈希处理和签名，因此请经常在后端使令牌无效并刷新（最好是对每个请求进行刷新）。
2. 应该有CSRF的对策。
3. 应强制执行SSL。