Security 使用客户端哈希设置密码

考虑到您确实必须在客户端执行密码哈希，如何实现服务器端加密

我能想到的第一个解决方案是在执行哈希之前从服务器的users表中请求用户的salt。但这意味着你在确认用户“存在”，因为你给了他用户的有效盐

我还认为，不必将盐存储在用户的表中，您可以使盐成为用户可以使用的东西，例如，他的用户名的变体。但是一致性问题可能会出现，因为服务器和客户机需要记住如何准确地从提供的用户数据中获取salt

---

最好的方法是什么？

我不是这方面的专家，但是在你提到的解决方案中使用一次性盐怎么样

也就是说，您为客户端提供了一个salt函数，该函数基于一个随机种子在短时间内生成一个salt。种子本身是动态的，在一段时间后会发生变化，并且在服务器和客户端之间必须相同。毕竟，盐不需要保密

在客户端，使用用户名（或任何可用的用户数据）生成salt，假设它是唯一的。然后在连接的密码和salt上生成散列，并将其发送到服务器上

---

在服务器端，使用客户端中相同的salt函数计算salt，并将用户名作为输入。然后生成相同的散列，并确定这两个值是否匹配。您只需确保时间窗口足够宽，以允许成功的身份验证。

如果您没有用于登录的HTTPS，则哈希客户端很有用，但它可能有一些缺点，例如暴露您的哈希和/或salt方法。也就是说，如果他们有权访问您的密码哈希数据库，他们可能已经有权访问该信息

为了只执行服务器端salt，您需要使用salt和password散列重新刷新密码。在这个场景中，您将只存储用户名、salt（如果不使用用户名和密码散列salt）和第二个散列

如果从您的示例中，您希望在客户端和服务器上执行salt，我建议使用用户名和初始密码哈希的组合来执行salt。客户端不会不知道salt，因为任何人都可以检查您的salt方法，甚至可以将其应用于密码破解程序，但这将避免他们使用彩虹表破解相同的密码用户

不要把用户名本身当作盐来使用。如果它是一个普通的用户名（例如admin），那么可能已经有一个表包含了这个salt

---

使用nyde1319的答案的问题（很抱歉没有对答案发表评论的权限）是，您需要在数据库中有一个未加密版本的密码才能执行密码+盐哈希。破坏散列的目的。如果使用散列版本的密码进行操作，您必须存储第一个散列，而他们可能会破解该散列，从而破坏salt的用途。

谁说您必须在客户端执行散列？我总是在服务器端进行操作。@Justin有时客户端哈希非常有用，尤其是当您不希望服务器访问明文密码时。我知道客户端的散列不能解决散列所要解决的安全问题，但在某些情况下，它可能很方便。