5

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

想象一下这种情况：

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

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

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

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

（想要这个的原因是不相关的，足以说用户的密码用于其他东西，例如文件加密）。

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

好的，这是问题：

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

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

我很难看到不利的一面。例如：

  • 没有重播攻击（因为会话是使用 SSL 加密的，所以攻击者看不到哈希值）
  • 无法查看数据库，因为散列本身就是，呃...，散列

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

欢迎提出想法，评论。

谢谢，

约翰

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

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

4

5 回答 5

4

考虑几件事：

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

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

于 2010-01-27T17:18:34.720 回答
3

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

于 2010-01-27T21:01:09.560 回答
2

这正是密码哈希器为网络浏览器所做的事情。

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

于 2010-01-27T20:54:20.513 回答
1

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

于 2010-01-28T09:11:01.007 回答
0

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

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

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

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

于 2010-01-27T17:10:27.157 回答