正在通过电缆发送哈希密码的安全漏洞？

Question

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

他们有一个我们需要整合的web服务。

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

如果我错了，随意翻阅我的理解，如上所述。

无论如何，回到手头的话题。这个潜在的合作伙伴运行的WebService不接受我期望的用户名和密码。它接受两个名为'Username'和'PasswordHash'的字符串字段。我给出的'PasswordHash'值确实看起来像一个散列，而不仅仅是一个错误密码字段的值。

这是为我提高红旗。我不确定为什么，但由于某种原因，我觉得通过电线发送散列密码会感到不舒服。关于我的头顶，我无法想到这将是一件坏事的原因......从技术上讲，无论如何，数据库中都有散列。但它让我感到紧张，而且我不确定是否有这个原因，或者我只是偏执狂。

编辑

我被一些评论困惑下面，直到我重新阅读我的文章。

原来，我有一句“只要密码通过明文提交给网站（或网络服务），一切都应该是可爱的。”

我发誓，因为我以为我在想'SSL'这个词。出于某种原因，我输入了“明文”这个词。哇。

最差。错字。永远。

Answer 1

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

如果系统接受散列密码，对于所有意图和目的，散列密码是的密码。如果攻击者获得哈希密码，他可以访问该帐户，而无需计算出原始密码。

上述所有问题的一个重要问题是，如果数据库受到攻击&攻击者获取哈希密码，这意味着通过所述WebService即时访问所有帐户，因为就WebService而言，密码。

我真的建议你把它带给他们&说说吧。这可能是某些开发人员没有获得关注/优先考虑的事情之一。

Answer 2

当涉及到安全性时，它很好是偏执狂，但在这种情况下，我不认为你有太多担心。哈希是严格的一种方式，所以永远不能转换回明文密码。接收方将只检查发送的散列值是否与他们存储的散列值相匹配。

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

Answer 3

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

你可以让所有的努力在世界上，但如果你没有使用SSL，您的验证过程可以轻轻松松被利用。