我遇到了一家公司正在使用的系统，我们正在考虑与中型（对我们而非他们）项目合作。
他们有一个我们需要整合的网络服务。
我目前对正确的用户名/密码管理的理解是用户名可以作为明文存储在数据库中。每个用户都应该有一个唯一的伪随机盐，它也可以以明文形式存储。他们的密码文本必须与salt连接，然后这个组合的字符串可以被散列并存储在nvarchar字段的数据库中。只要密码通过 SSL 提交到网站（或网络服务），一切都应该是可爱的。
如果我错了，请随意撕开我上面总结的理解。
无论如何，回到手头的主题。此潜在合作伙伴运行的WebService不接受我预期的用户名和密码。相反，它接受两个名为“Username”和“PasswordHash”的字符串字段。我给出的'PasswordHash'值确实看起来像一个哈希值，而不仅仅是一个错误命名的密码字段的值。
这对我来说是一个红旗。我不知道为什么，但出于某种原因，我觉得在电线上发送哈希密码感到很不舒服。在我的脑海中，我无法想到为什么这会是一件坏事...从技术上讲，无论如何，数据库都可以使用哈希。但它让我感到紧张，我不确定是否有这样的原因，或者我是否只是偏执狂。
修改
在我重新阅读我的帖子之前，我对下面的一些评论感到困惑。
在原文中，我有一句“只要密码通过明文提交到网站（或网络服务），一切都应该是可爱的。”
我发誓，因为我认为我在想“SSL”这个词。出于某种原因，我输入了“明文”这个词。哇。
最差。错字。如初。
答案 0 :(得分：11)
使用散列密码将其发送到服务没有任何价值，因为您仍然需要一个单独的机制来保护通信，即SSL
如果系统接受散列密码，则出于所有目的和目的，散列密码是密码。如果攻击者获得了哈希密码，他可以访问该帐户而无需找出原始密码。
上述所有问题的一个重要问题是，如果数据库受到损害，那么攻击者获取哈希密码，这意味着通过所述WebService即时访问所有帐户，因为只要WebService关注那些密码就已经存在了。
我真的建议你把它带给他们＆amp;说说它。这可能是某些开发者做过的事情之一＆amp;没有引起人们的注意/优先考虑。
答案 1 :(得分：3)
在安全性方面偏执是好事，但在这种情况下，我不认为你有太多担心。哈希是严格的一种方式，因此永远不能转换回明文密码。接收方只需检查发送的哈希值是否与它们存储的哈希值匹配。
唯一需要关注的是确保在传输过程中没有人能够窃听散列密码，因此应该使用SSL之类的东西。如果有人在传输中嗅探用户名+哈希密码，攻击者可以重复使用它。
答案 2 :(得分：2)
除了详细信息，这是一个容易回答的问题：
您可以在全球范围内付出全部努力，但如果您不使用SSL，您的身份验证过程可能会被轻松利用。