通过网络发送散列密码是否存在安全漏洞？答案

【问题标题】：Is sending a hashed password over the wire a security hole?通过网络发送散列密码是否存在安全漏洞？
【发布时间】：2010-04-30 06:41:38
【问题描述】：

我遇到了一家公司正在使用的系统，我们正在考虑与该公司合作开展一个中型（对我们而言，而不是他们）项目。

他们有一个我们需要与之集成的网络服务。

我目前对正确的用户名/密码管理的理解是用户名可以以明文形式存储在数据库中。每个用户都应该有一个唯一的伪随机盐，它也可以以明文形式存储。他们的密码文本必须与盐连接，然后这个组合字符串可以被散列并存储在数据库中的 nvarchar 字段中。只要通过 SSL 将密码提交到网站（或网络服务），一切都应该是美好的。

如果我错了，请随意撕毁我上面总结的理解。

无论如何，回到手头的主题。这个潜在合作伙伴运行的 WebService 不接受用户名和密码，这是我所预料的。相反，它接受两个名为“用户名”和“密码哈希”的字符串字段。我得到的“PasswordHash”值确实看起来像一个哈希，而不仅仅是一个错误命名的密码字段的值。

这对我来说是一个危险信号。我不知道为什么，但出于某种原因，我对通过网络发送散列密码感到不舒服。在我的脑海中，我想不出为什么这会是一件坏事的原因......从技术上讲，哈希无论如何都可以在数据库中使用。但这让我很紧张，我不确定这是有原因还是我只是偏执。

编辑

在我重新阅读我的帖子之前，我被下面的一些 cmets 弄糊涂了。

在原文中，我有一句话“只要通过纯文本向网站（或网络服务）提交密码，一切都应该是美好的。”

我发誓，因为我认为我在考虑“SSL”这个词。出于某种原因，我输入了“纯文本”这个词。哇。

最糟糕的。错字。永远。

【问题讨论】：

标签： security hash login passwords

【解决方案1】：

使用散列密码将其发送到服务没有任何价值，因为您仍然需要一个单独的机制来保护通信，即 SSL

如果系统接受散列密码，则散列密码就是密码。如果攻击者获得了散列密码，他就可以访问该帐户而无需找出原始密码。

以上所有内容的一个重要问题是，如果数据库被破坏并且攻击者获得散列密码，这意味着通过所述 WebService 即时访问所有帐户，因为只要 WebService 关心这些已经是密码。

我真的建议你把它带给他们并谈论它。这可能是一些开发者做过的事情之一，但没有引起注意/优先解决它。

【讨论】：

感谢弗雷迪。我想我会的——不过，很高兴知道它没有我最初担心的那么糟糕。
Freddy 是对的：散列密码就是密码。除非“哈希”是由服务器首先发送随机随机数形成的，并且客户端使用随机数对密码进行哈希处理——这是允许的。但是不要去重新发明轮子......
实际上，哈希密码只是该站点的密码。如果哈希包含 nonce/salt 客户端，那么拦截器将无法在另一个站点上重用该密码。当然 - 仅 - 客户端哈希是不可接受的，但它可能会增加一些混淆。
@Tchalvak：您评论的第一部分 +1。这是开发人员经常忘记的一件事 - 通过散列，我们可以保护 OTHER 网站上的用户密码。无论如何，我们的网站都会受到威胁（如果数据库内容被盗）。

【解决方案2】：

在安全方面偏执是件好事，但在这种情况下，我认为您不必担心太多。哈希严格来说是一种方式，因此永远无法转换回明文密码。接收方将简单地检查发送的哈希值是否与他们存储的哈希值匹配。

唯一的问题是确保在传输过程中没有人可以窃听散列密码，因此应该使用 SSL 之类的东西。如果有人在传输过程中嗅探用户名 + 散列密码，它可能会被攻击者重用。

【讨论】：

如果散列密码用 sessionid 或其他东西加盐会更好。但当然，这也可以被嗅探
@TiansHUo 只要您可以访问交换的信息，您就可以访问盐，我怀疑有任何理由。 OP 应该与他们交谈并找出发生了什么。
谢谢你 - 当我坐下来仔细考虑时，我的想法反映了这一点。我只是想确定一下。如果我能做不止一个，我会把你作为正确答案添加，但我必须把它交给下面的 Freddy Rios，因为我认为他建议我至少向另一家公司的开发人员提及它是正确的，以防万一他们错过了。

【解决方案3】：

抛开细节不谈，这是一个很容易回答的问题：

您可以尽一切努力，但如果您不使用 SSL，您的身份验证过程可能轻松被利用。

【讨论】：