在（服务器端）会话中的用户对象中存储散列密码是不可取的吗？不言而喻，需要在某个时刻检索盐渍和散列密码以比较散列以验证给定用户，但是一旦进行比较，是否存在与将其保留在用户对象中相关联的可量化安全风险？ / p>
鉴于评论中的讨论，问题的要点是密码和散列数据将存储在用户对象中，其余的用户数据一旦从一个干净的调用中从数据库中检索出来。我在发布问题之前已经理解了当然存在风险，但是它是否足够可行以保证实施框架以从用户中清除它，或者这样做是否等于良好实践？
鉴于回复，我认为最好的解决方案是拥有一个凭证对象，其中包含通过ID与用户关联但不直接存储在其中的密码和盐。
当用户尝试登录时，将通过电子邮件/用户名从数据库中检索用户对象（不包含密码数据）。然后读取ID并用于检索关联的凭证对象。然后可以进行密码验证。如果密码正确，则会将用户置于会话中并销毁凭证对象。
结果是一个没有密码数据的用户对象，因此可以避免任何潜在的相关安全风险（无论它们可能是最小的，如问题中所讨论的）。另一个结果是在使用之前没有手动清除用户对象的密码数据。这是一个比每次都要求清除数据更可靠的系统，如果使用EF或类似技术，当对象的更改被推送到数据库时，不存在意外删除密码数据的风险
答案 0 :(得分：5)
我个人认为没有任何理由不这样做。如果salted哈希是安全的，那么将它存储在服务器端会话中的安全性应该不比将其存储在数据库中更安全。
毕竟，使用好的盐腌哈希的重点是，即使您的数据库遭到入侵并且某人获得了所有盐渍哈希，他们仍然无法恢复实际密码。
答案 1 :(得分：1)
假设您信任您的服务器，我认为这不会过于安全。
对于理想的密码哈希，哈希的泄漏并不是非常重要的。如果盐未暴露，则实际上无法恢复密码。如果构造哈希的salt和元素被暴露（除了密码），那么它就变得可能，但通常是不切实际的，因为彩虹表是无用的，而暴力是唯一的方法。如果你使用强大的散列算法，如SHA256或Bcrypt，你不必担心......
现在有人说，我绝对不建议只给陌生人提供密码哈希，但保留在你的服务器上应该几乎没有任何安全隐患
答案 2 :(得分：1)
如果您的会话未针对客户端站点存储进行序列化，则没有与之相关的imidiate威胁。但是如果你必须在会话中存储哈希值，那么你应该修改你的身份验证/授权逻辑，以便更好地进行应用程序设计。