使用 SSL 的密码哈希

Question

好的，这听起来像是一个奇怪的问题。跳上我之前请仔细阅读好吗？ ;-)

想象一下这种情况：

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

好的，是的，我意识到这听起来很奇怪。是的，整个对话都在 SSL 中，所以你可以只发送密码明文。是的，我意识到可以以散列形式安全地存储明文密码。

这就是我要强调的一点：真诚地说“我们永远不会知道您的密码”对我们的业务很有用。

请注意，我并不是说“我们不会以明文形式存储您的密码”，而是说我们真的、永远不会知道它；你永远不会把它给我们。

（想要这个的原因无关紧要，足以说明用户的密码用于其他用途，例如文件加密）。

是的，我知道您可能会说，以正常的方式执行此操作“在您进行散列时，密码只会在内存中以明文形式保存 5 毫秒”，但这更多是关于可否认性。即，我们可以说 100% 我们甚至没有收到您的密码。

好的，问题来了：

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

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

我很难看到缺点。例如：

• 无重放攻击（由于会话是使用 SSL 加密的，因此攻击者看不到哈希值）
• 无法在数据库中查找，因为哈希本身就是哈希，呃...，哈希

好吧，你现在可以跳到我身上了 :)

想法，欢迎cmets。

谢谢，

约翰

更新：只是想澄清一下：我并不是说这是对身份验证过程的安全性的某种改进。但是，相反，它允许用户的“真实”密码保密，甚至对服务器也是如此。因此，如果真实密码用于加密文件，则服务器无权访问该密码。

我对我想要这个的理由完全满意，问题是它是否是身份验证过程安全性的障碍。

Answer 1

所以在这一点上，真的一点帮助都没有。让我们假设您的 SSL 以某种方式受到了损害。他们嗅探散列+加盐的密码。然后他们可以在您的服务器接受散列+加盐密码作为他们的密码时发送该密码。您所做的只是增加了一层复杂性（无法在密码框中输入密码），在这种情况下，他们可以手动将其发布到您的服务器。

更不用说它是否在客户端完成了，你不仅要交给他们你的散列算法，还有你的盐以及你如何组合它。

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

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

Answer 2

考虑以下几点：

1. 客户端必须决定盐和哈希。
2. 在 (1) 中创建散列的任何内容都可能很容易被攻击者发现
3. 盐和哈希必须一致。如果盐值发生变化，哈希值也会发生变化，然后您的服务器将无法将其哈希回原来的值。
4. salt + hash 基本上成为了用户的新密码。
5. 如果他们的原始密码比盐 + 哈希值长，您可能只是降低了他们密码的安全性（假设密码良好并忽略哈希冲突）。
6. 但是，如果他们的密码很差，您可能只是提高了他们的密码质量（忽略上面的 1 和 2 哈希冲突）。

最终的结果是盐+密码成为了他们的新密码。总的来说，我同意大多数人的看法，这样做没有什么好处。

Answer 3

这正是password hashers 为网络浏览器所做的事情。

每个人对你的想法的问题不在于这是一个坏主意；而是只是，因为您是客户端和服务器的开发人员，信任客户端的计算机而不是服务器不会给您带来任何真正的好处（毕竟，客户端可能有键盘记录器或某物）。所以回答你的问题：这对你来说只是一个障碍。

Answer 4

在我看来，这个计划有一个我没有提到的好处（也许我错过了）。人们当然可以争辩说哈希+盐成为真正的密码。但是，就重复使用密码的人的安全性而言，它增加了价值。如果我在您的网站上使用我的密码“asdfasdf”并且有人破坏了您的服务器，他们将无法提取我在 dubdubdub.superfinance.com 上使用的密码。

Answer 5

除了上面提到的问题之外的另一个问题：除非您再次对接收到的值进行散列和加盐，否则您实际上是在以明​​文形式存储所有密码。任何获得数据库读取权限的攻击者都可以轻松地以任何用户身份进行身份验证。