鉴于你真的必须在客户端执行密码散列，你如何实现服务器端salting？
我能想到的第一个解决方案是在执行哈希之前从服务器的users表中请求用户的salt。但这意味着你确认用户“存在”，因为你给了他用户的有效盐。
我还认为，不是将盐存储在用户的表中，您可以将盐用于用户可用的内容，例如，用户名的变体。但是可能会出现一致性问题，因为服务器和客户端需要记住从提供的用户数据中获取盐的确切程度。
这样做的最佳方式是什么？
答案 0 :(得分：1)
我不是关于这个主题的专家，而是如何使用像一次性盐这样的东西以及你提到的解决方案。
意思是，您为客户端提供了一个盐析函数，该函数在短时间内基于随机种子生成盐。种子本身是动态的，并且在一段时间后会发生变化，并且服务器和客户端之间必须是相同的。毕竟，盐不需要保密。
在客户端使用用户名（或任何可用的用户数据）生成salt，假设它是唯一的。然后在连接的密码和salt上生成哈希并将其发送到服务器上。
在服务器端，您使用用户名作为输入在客户端中使用相同的salting函数计算salt。然后生成相同的哈希，并确定这两个值是否匹配。您只需确保时间窗口足够宽，以便成功进行身份验证。
答案 1 :(得分：1)
如果您没有用于登录的HTTPS，则哈希客户端非常有用，但它可能有一些缺点，例如泄露您的哈希和/或腌制方法。话虽这么说，如果他们可以访问您的密码哈希数据库，他们可能已经可以访问该信息。
要仅执行服务器端salt，您需要使用salt和password哈希重新密码。在这种情况下，您只存储用户名，salt（如果不使用用户名和密码哈希盐）和第二个哈希值。
如果从您的示例中您希望在客户端和服务器上执行salting，我建议使用用户名和初始密码哈希的组合来加盐。客户不知道盐，因为任何人都可以检查您的盐渍方法甚至将其应用于密码破解程序，但它将避免使用彩虹表来破解相同的密码用户。
不要将用户名本身用作盐。如果它是一个通用的用户名（例如admin），那么可能已经有一个表格已经存在这个盐。
使用nyde1319的答案（抱歉没有权利对答案发表评论）的问题是，您需要在数据库中使用未加密的密码版本才能执行密码+ salt哈希值。击败哈希的目的。如果它是使用密码的哈希版本完成的，那么你必须存储第一个哈希，他们可能只是破解那个哈希，从而破坏了盐的目的。