Security 在客户端散列密码有安全意义吗

如果在发送用户密码之前先对其进行散列，然后将其以明文形式保留在内存中，这会提高应用程序的安全性吗

我认为这可以通过保护存储在客户机内存中的数据来减少一小部分漏洞。但如果我们真的担心有人读取客户的内存，那么可能还有更大的问题我们无法解决

在客户端进行散列有一些不正确的地方

客户端上的密码散列是常见的做法吗？做这件事还有其他的优点或缺点吗

编辑：

---

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

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

哈希与您描述的场景中安全POV的密码相同：如果我截取哈希，我不需要知道密码，我只需将截取的哈希发送给服务器即可

尽量避免这个问题；安全性很难实现，最好选择并实现一个易于理解的协议，而不是使用自己的协议

如果您的流量是通过SSL传输的，那么您就不会被拦截，而散列不会给您带来额外的好处。

否

当客户端发送某个内容时，无论是

p

还是

H（p）

还是

H（H（p））

任何截取该内容的人都可以简单地重新发送完全相同的内容，从而使任何类似的功能都相当于直接使用密码

这就是为什么你应该使用；服务器可以发出一些随机垃圾

k

，客户端将计算

H（P，k）

，并将其发送到服务器。是此方法的流行实现

---

如果服务器从未两次接受同一个nonce，则可以防止重播攻击。

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

它所做的是阻止观看数据包的人提取密码，这是相当有用的。许多人在多个站点上使用相同的密码（我只对安全性较高的站点使用相同的密码），因此，如果您可以从他们那里获得一个密码，您可以登录其他站点上的其他帐户

它还可以防止真实密码被存储在您的站点上，即使是暂时的，如果您的站点被破坏，这可能会提供一点额外的安全性

这样，虽然我认为用户端散列是一个潜在的好东西，但它不值得额外的麻烦。

---

而且，正如其他人告诉你的，不要使用自己的安全措施。可能出错的事情太多了。你不会像一个老练的坏蛋那样快地注意到它们。

如果你使用（SRP），你会过得更好。它就是为此而设计的。

不，在客户端进行哈希运算并不能“完全”保护密码。当一个人选择在客户端散列密码时，提交给服务器的摘要实质上就是密码。如果部署了SSL，这本身就不是问题

然而，这个方案最终产生的问题比它解决的问题还要多。如果服务器将客户端提交的散列与数据库中存储的散列进行比较，而不执行任何进一步的加密操作（尤其是对输入数据进行散列），则出于所有实际目的，密码以明文存储。任何有权访问存储哈希的人都可以将其重新提交到服务器并获得对帐户的访问权

简单来说，如果提交的散列（与提交的散列相同）通过应用程序内的任何其他漏洞（例如，通过SQL注入）泄漏，则应用程序存在一个漏洞，其中对密码的保护不足

---

如果必须修复潜在的漏洞，则有必要将提交的哈希作为明文密码处理，然后在与存储的哈希进行比较之前对其进行哈希（最好使用salt）。客户端的哈希打开了另一个大漏洞：您可能会暴露哈希算法。您不会说这是基于web的（client=JavaScript）还是厚客户端，但您会给他们提供更多信息。鉴于通道是安全的，您不必担心明文密码被监听

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

是的，您应该这样做

IEEE有一次数据泄露事件，10万封电子邮件和密码从一个博客中泄露

显然，IEEE不应该公开他们的博客！但如果他们在客户端对密码进行哈希运算，情况就不会那么糟糕了

---

正如第一个答案所述，您应该使用nonce。如果使用足够长的nonce（例如128位），就不必担心重用问题，因为服务器永远不会要求相同的nonce两次（假设正确播种了CRNG等）。

我认为这在一种情况下是有意义的；你甚至不想知道客户的明文密码。如果您在客户端进行散列，那么salt和迭代散列将以与明文pw相同的方式进行散列。除此之外，这有点傻。