authentication - 在 SSL 中使用密码哈希

Question

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

想象一下这种情况:

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

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

这就是我要表达的观点:真诚地说“我们永远不会知道您的密码”对我们的业务很有用。

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

(想要这个的原因无关紧要，只要说用户的密码用于其他东西，例如文件加密就足够了)。

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

好的，问题来了:

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

• 这样做的安全隐患是什么？

我很难看到缺点。例如:

• 没有重放攻击(因为对话是使用 SSL 加密的，攻击者看不到哈希值)
• 无法查看数据库，因为散列本身就是散列，呃...，散列

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

欢迎提出想法和评论。

谢谢，

约翰

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

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

Answer 1

考虑一些事情:

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

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