c# – 在会话中存储散列密码是不可取的吗？
发布时间：2020-12-16 01:51:52 所属栏目：百科 来源：网络整理
导读：在(服务器端)会话中将散列密码存储在用户对象中是不可取的吗？不言而喻,需要在某个时刻检索盐渍和散列密码以比较散列以验证给定用户,但是一旦进行比较,是否存在与将其保留在用户对象中相关的可量化安全风险？ 鉴于评论中的讨论,问题的要点是密码和散列数据将
|
在(服务器端)会话中将散列密码存储在用户对象中是不可取的吗？不言而喻,需要在某个时刻检索盐渍和散列密码以比较散列以验证给定用户,但是一旦进行比较,是否存在与将其保留在用户对象中相关的可量化安全风险？
鉴于评论中的讨论,问题的要点是密码和散列数据将存储在用户对象中,其余的用户数据一旦从一个干净的调用中从数据库中检索出来.我在发布问题之前已经明白了,当然存在风险,但是它是否足够可行以保证实施一个框架以便从用户那里清除它,或者这样做是否恰好是一种良好的做法？ 鉴于响应,我认为最好的解决方案是拥有一个凭证对象,其中包含通过ID与用户关联但不直接存储在其中的密码和盐. 当用户尝试登录时,将通过电子邮件/用户名从数据库中检索用户对象(不包含密码数据).然后读取ID并用于检索关联的凭证对象.然后可以进行密码验证.如果密码正确,则将用户置于会话中并销毁凭证对象. 结果是没有密码数据的用户对象,因此避免了任何潜在的相关安全风险(无论它们可能是最小的,如问题中所讨论的).另一个结果是在使用之前没有手动清除用户对象的密码数据.这是一个比每次都要求清除数据更可靠的系统,如果使用EF或类似技术,当对象的更改被推送到数据库时,不存在意外删除密码数据的风险. 解决方法
我个人认为没有任何理由不这样做.如果salted哈希是安全的,那么将它存储在服务器端会话中应该不比将其存储在数据库中更安全.
毕竟,使用好的盐腌哈希的重点是,即使您的数据库遭到入侵并且某人获得了所有盐渍哈希,他们仍然无法恢复实际密码. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |