在（服务器端）会话中的用户对象中存储散列密码是否不可取？不言而喻，需要在某个时候检索加盐和散列的密码以比较散列以验证给定用户，但是一旦进行比较，是否存在与将其保存在用户对象中相关的可量化的安全风险？
鉴于评论中的讨论，问题的要点是密码和哈希数据将存储在用户对象中，一旦从数据库中检索到其余用户数据，则只需一次干净的调用。在发布这个问题之前，我明白当然存在风险，但它是否足以保证实施一个框架以从用户那里清除它，或者这样做只是一种良好的做法？
鉴于响应，我认为最好的解决方案是拥有一个包含密码和盐的凭据对象，该对象通过 ID 与用户相关联，但不直接存储在其中。
当用户尝试登录时，会通过电子邮件/用户名从数据库中检索用户对象（不包含密码数据）。然后读取 ID 并将其用于检索关联的凭证对象。然后可以进行密码验证。如果密码正确，则将用户置于会话中并销毁凭据对象。
结果是一个没有密码数据的用户对象，因此可以避免任何潜在的相关安全风险（尽管它们可能很小，如问题中所讨论的那样）。另一个结果是在用户对象使用之前没有手动清除用户对象中的密码数据。这是一个比要求每次都清除数据更可靠的系统，并且如果使用 EF 或类似技术，则不会在将对象的更改推送到数据库时意外删除密码数据的风险。