在客户端散列密码是否有安全意义

Question

如果您要在将用户密码发送到线路之前对其进行哈希处理并将其保留为内存中的纯文本，这是否会提高应用程序的安全性？

我认为这可以通过保护存储在客户端内存中的数据来缓解一小部分漏洞。但实际上，如果我们担心有人在阅读客户的记忆，那么我们可能无法解决更大的问题。

对于客户端的散列，有些东西感觉不对。

客户端上的密码哈希是一种常见的做法吗？这样做还有其他优点或缺点吗？

编辑： 鉴于通信信道是安全的（SSL）。在什么条件下使用这种方法是可以接受和值得的。我问这个是因为“安全专家”建议我在某些应用程序功能中使用这样的方案。

Answer 1

没有

当客户端发送某些内容时，无论是P还是H(P)还是H(H(P))，任何拦截此内容的人都可以重新发送完全相同的内容，从而使这样的任何功能等同于直接使用密码。

这就是你应该使用nonce的原因;服务器可以发出一些随机垃圾k，客户端将计算H(P,k)并将其发送到服务器。 HMAC是此方法的常用实现。

如果服务器从不接受两次相同的nonce，这对于重放攻击是安全的。

Answer 2

哈希与您描述的场景中的安全POV的密码相同：如果我拦截哈希，我不需要知道密码，我只能向服务器发送我截取的哈希值。

Authentication protocols为了避免这个问题需要一定的时间;安全性很难，你最好选择和实现一个易于理解的协议，而不是自己动手。

如果你的流量超过了SSL，你就可以安全地拦截并且散列给你带来额外的好处。

Answer 3

发送散列密码不会提高您网站的安全性，正如其他人所指出的那样（因为您接受哈希密码，所有坏人需要知道的是哈希版本）。它也不是很安全，因为坏人可能会加载你的登录页面并检查部署的Javascript或Java。

它所做的是阻止有人看到数据包能够拔出密码，这是适度有用的。许多人在多个站点上使用相同的密码（除了安全性较高的站点之外，我都使用相同的密码），因此如果您可以从中获取一个密码，则可以登录其他站点上的其他帐户。

它还可以防止真实密码在您的网站上存储，甚至暂时存储，如果您的网站遭到入侵，这可能会提供额外的安全保障。

因此，虽然我认为用户端散列可能是一件好事，但是不值得花费额外的麻烦。

而且，正如其他人告诉你的那样，不要自己动手。有太多可能出错的事情。你几乎不会像练习坏人一样快速地注意到它们。

Answer 4

是的，你应该。

IEEE发生了数据泄露事件，其中100K电子邮件和密码是从博客中暴露出来的。

http://ieeelog.com/

显然，IEEE不应该暴露他们的博客！但如果他们在客户端窃取了密码，那就不会那么糟糕。

正如第一个回答所述，你应该使用一个随机数。如果你使用足够长的随机数（例如128位），你实际上不需要担心重用，因为服务器永远不会要求两次相同的随机数（假设正确播种的CRNG等）。

Answer 5

不，客户端的散列不能完全保护密码。当一个人选择在客户端散列密码时，提交给服务器的摘要基本上就成了密码。如果部署SSL，这本身就不是问题。

但是，这种方案最终会产生比解决的问题更多的问题。如果服务器将客户端提交的哈希值与数据库中存储的哈希值进行比较而不执行任何进一步的加密操作（尤其是哈希输入数据），那么密码将以明文形式存储实际目的。任何有权访问存储哈希的人都可以将其重新提交给服务器并获得对帐户的访问权。

简单来说，如果提交的哈希值（与提交的哈希值相同）是通过应用程序中的任何其他漏洞泄漏（例如，通过SQL注入），那么应用程序就有一个漏洞，其中保护了密码不充分。

如果必须修复基础漏洞，则必须将提交的散列视为明文密码，然后在与存储的散列进行比较之前对其进行散列（最好使用salt）。

Answer 6

确保您通过安全通道（SSL）发送密码。如果客户端可以读取应用程序私有内存，那么很可能它们有更大的问题，例如键盘记录器。

Answer 7

我认为在某种情况下这是有道理的;你甚至不想知道客户的明文密码。如果你在客户端散列，那么salt和迭代地散列该散列的方式与明文pw相同。除此之外，它有点傻。

Answer 8

如果你使用Secure Remote Password protocol（SRP），你会好得多。它是为此而设计的。

Answer 9

我可以给你不同的方法 如果您没有SSL ，您可以在客户端散列密码，然后再次使用其他散列方法在服务器端散列并将其存储在数据库中 当用户使用密码登录时执行相同的过程并将双哈希密码与存储的哈希匹配

Answer 10

是的，即使您使用 SSL，在客户端对密码进行哈希处理也是有意义的，但您仍然必须在服务器端再次对其进行哈希处理。

这在移动应用的情况下尤其有意义。如果您在客户端散列即使使用“常量盐”/域字符串，它也会比以明文发送密码好得多，即使您使用 SSL。如果您将明文密码发送到服务器，那么万一有人入侵您的服务器，他将收到明文密码。因此，在客户端添加额外的预散列可以保护用户及其密码，他们可能也在其他地方使用这些密码。

您可能会发现很多帖子都说不需要客户端散列，但它们通常与网络应用程序相关并且不考虑移动应用程序案例。在 Web 应用程序的情况下，如果有人攻击服务器，他可以替换网站并删除客户端散列，因此在这种情况下没有那么大的优势。但是对于移动应用程序，攻击者无法替换移动应用程序的代码，因此在这种情况下，客户端的哈希处理很有意义。

您可以检查此链接以获取在客户端和服务器端进行散列的可能解决方案：https://medium.com/@harwoeck/password-and-credential-management-in-2018-56f43669d588

所以是的，在客户端和服务器端都散列。

Answer 11

在客户端进行哈希打开了另一个巨大漏洞：您可能会暴露哈希算法。您没有说这是基于Web的（客户端= JavaScript）还是胖客户端，但您提供的信息更多。鉴于频道是安全的，您不必担心明文密码被嗅探。

此外，如果您的哈希算法需要盐，您将暴露您的盐，这意味着如果他们有权访问数据库，他们将能够解密每个密码。