使用SSL密码哈希

Question

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

想象一下这种情况：

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

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

以下是我的观点：我们的业务真实地说“我们永远不会知道您的密码”。

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

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

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

好的，这就是问题：

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

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

我很难看到下行空间。例如：

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

好的，你现在可以跳我：）

思考，欢迎评论。

谢谢，

约翰

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

我对我想要这个的原因感到非常满意，问题是它是否是阻碍对身份验证过程的安全性。

Answer 1

考虑一些事情：

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

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

Answer 2

在我看来，这个方案有一个好处，我没有看到提到（也许我错过了）。可以肯定的是，hash + salt成为真正的密码。但是，就重用密码的人的安全性而言，它增加了价值。如果我在您的网站上使用我的密码'asdfasdf'并且有人危及您的服务器，他们将无法提取我在dubdubdub.superfinance.com上使用的密码。

Answer 3

这正是password hashers对网络浏览器的作用。

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

Answer 4

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

Answer 5

所以在这一点上，它根本没有帮助。让我们假设您的SSL已被泄露。他们嗅到哈希+盐渍密码。然后他们可以发送它，因为您的服务器接受哈希+盐渍密码作为他们的密码。您正在做的只是添加一层复杂性（无法在密码框中输入密码），在这种情况下，他们可以手动将其发送到您的服务器。

更不用说如果它完成了客户端，你不仅要处理它们的哈希算法，还要处理你的盐以及你如何组合它。

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

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