使用SSL密码哈希

Question

好吧,这可能听起来像一个奇怪的问题.在跳我之前请仔细阅读好吗？;-)

想象一下这种情况:

1. 我们有一个服务器和一个客户端.
2. 他们使用SSL连接.
3. 客户端使用密码在服务器上创建帐户
4. 但是,他实际通过网络传递给服务器的是密码的哈希(+盐)(不是密码)
5. 服务器在DB中保存此接收的密码哈希值(使用盐哈希)
6. 在登录时,要进行身份验证,用户重新发送密码哈希值(不是密码!).

好的,是的,我意识到这听起来很奇怪.是的,整个会话都在SSL中,所以你可以发送密码明文.是的,我意识到可以安全地存储明文密码.

以下是我的观点:对我们的业务来说,真实地说"我们永远不会知道您的密码"是​​有用的.

注意我不是说"我们不以明文形式存储您的密码",但我们真的,从来没有,知道它; 你永远不会把它给我们.

(想要这个的原因是不相关的,足以说用户的密码用于其他东西,例如文件加密).

是的,我意识到你可能会说正常的做法是"在你进行散列时,密码只能在内存中以明文形式显示5ms",但这更多是关于否定性.即,我们可以说100%我们甚至没有收到您的密码.

好的,这就是问题所在:

• 以前有人做过或听说过这种事吗？

• 这样做有什么安全隐患？

我很难看到一个缺点.例如:

• 没有重播攻击(因为会话使用SSL加密,攻击者无法看到哈希)
• 无法查看数据库,因为哈希本身就是哈希...,哈希

好的,你现在可以跳我:)

想法,欢迎评论.

谢谢,

约翰

更新:只是想澄清:我并不是说这在某种程度上改善了身份验证过程的安全性.但是,它允许用户的"真实"密码保持秘密,即使是从服务器.因此,如果真实密码用于加密文件,则服务器无权访问.

我完全满足于我想要这个的原因,问题是它是否会妨碍身份验证过程的安全性.

Answer 1

所以在这一点上，真的没有任何帮助。让我们假设您的 SSL 已被泄露。他们嗅探经过哈希处理和加盐处理的密码。然后，当您的服务器接受散列+加盐密码作为他们的密码时，他们就可以发送该密码。您所做的只是添加一层复杂性（无法在密码框中输入密码），在这种情况下，他们可以手动将其发布到您的服务器。

更不用说如果它是在客户端完成的，您不仅要向他们提供您的哈希算法，还要向他们提供您的盐以及您如何组合它。

总结：我认为没有什么太大的好处，但我可能是错的。

我个人在服务器端实现了哈希+加盐，并在登录页面上强制使用 SSLv3/TLSv1。