是否不建议在会话中存储散列密码？
在(服务器端)会话中的用户对象中存储散列密码是不明智的吗？不用说，需要在某个点检索咸密码和散列密码，以比较哈希以验证给定用户，但一旦进行了比较，是否存在与将其保存在用户对象中相关的可量化的安全风险？
考虑到注释中的讨论，问题的要点是密码和散列数据将存储在用户对象中，其余的用户数据将在一个干净的调用中从数据库中检索出来。在发布这个问题之前，我了解到，当然存在风险，但它是否有足够的可行性来保证实现一个框架来从用户那里清除它，或者这样做只是一种良好的实践呢？
考虑到响应，我认为最好的解决方案是拥有一个凭据对象，其中包含通过ID与用户关联但不直接存储在其中的密码和salt。
当用户尝试登录时，用户对象(不包含密码数据)将通过电子邮件/用户名从数据库中检索。然后读取ID并用于检索关联的凭据对象。然后可以进行密码验证。如果密码正确，则用户将进入会话，凭据对象被销毁。
结果是一个没有密码数据的用户对象，因此避免了任何潜在的相关安全风险(无论这些风险多么小，正如问题中所讨论的那样)。另一个结果是，用户对象在使用之前没有手动清除密码数据。这是一个比每次都要求清除数据更可靠的系统，如果使用EF或类似技术，则在将对象的更改推送到数据库时不会意外删除密码数据。
回答 3
Stack Overflow用户
发布于 2012-12-11 20:51:50
就我个人而言，我不认为有什么理由不这样做。如果盐析散列是安全的，那么将其存储在服务器端会话中不应该比将其存储在数据库中更安全。
毕竟，使用一个好的盐度散列的全部意义是，即使您的数据库被破坏，并且有人获得了所有的咸散列，他们仍然无法恢复实际的密码。
Stack Overflow用户
发布于 2012-12-11 20:52:21
假设您信任您的服务器，我认为这不会太不安全。
对于理想的密码哈希，散列泄漏并不是非常关键的。如果盐没有暴露，那么实际上不可能恢复密码。如果构建哈希的salt和元素被公开(密码除外)，那么它就有可能出现，但通常是不切实际的，因为彩虹表是无用的，而蛮力是唯一的方法。如果您使用强散列算法(如SHA256或Bcrypt )，您不应该担心太多。
话虽如此，我绝对不建议只给陌生人密码哈希，但是把密码保存在服务器上应该没有什么安全隐患。
Stack Overflow用户
发布于 2012-12-11 20:52:42
如果您的会话未序列化为客户端站点存储，则不存在与此相关的imidiate威胁。但是，如果您必须在会话中存储散列，那么您应该修改身份验证/授权逻辑，以获得更好的应用程序设计。
https://stackoverflow.com/questions/13828259
复制相似问题
腾讯云开发者
