我假设您正在谈论额外的散列。所以它看起来像这样：

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

_{我想你已经意识到了这一点，但只是为了明确一点：传输需要通过 SSL 进行以防御窃听者，散列客户端对他们根本没有帮助。}

散列或混淆密码客户端可以很好地缓解密码重用：

即使攻击者在传输中或在服务器上以明文形式访问密码，它仍然会被散列，因此攻击者无法在不首先破解散列的情况下在其他网站上尝试相同的凭据。

在我看来，如果攻击者可以拦截我的登录请求，那么无论我是否尝试混淆它，他都可以稍后重放它。

是的。散列客户端不会为您的应用程序增加任何安全性，唯一的优点是它可以减轻不良用户行为，这可能会影响用户也在使用的其他应用程序。

请注意，它甚至不能保护您的应用程序免受密码重用，因为从另一个应用程序获得用户凭据的攻击者只会对其进行哈希处理并尝试这样做。

它也不会为破解您存储的哈希的过程增加任何复杂性。攻击者不会尝试将哈希列表作为输入，而是尝试使用普通的单词列表，他们将首先通过 sha1。

正如 tim 所写，在某些情况下，它可以帮助减轻用户密码重用的影响，但如果您正在考虑的是在客户端而不是在服务器端散列它，这将是一个主要的设计缺陷。

https://en.wikipedia.org/wiki/Pass_the_hash

这个问题困扰着 NTLM 身份验证，它实际上比常见的 Web 应用程序/服务场景更糟糕，因为哈希通常缓存在处理身份验证的服务器之外的系统上。

您的 sha1 密码只是成为滴管的普通密码。

我要做的是：

在数据库上，每个密码都使用 bcrypt 和 salt 加密。盐是“公共的”。

当用户登录时，会发生以下情况： -> 客户端发送用户名 -> 服务器回复“salt” -> 客户端生成随机随机数 -> 客户端发送“bcrypt(nonce+bcrypt(salt+password)+time)+ + time+nonce" -> 服务器检查 nonce 在过去 5 分钟内没有被使用，然后进行密码检查。它是通过将客户端发送的输入与“bcrypt(nonce+dbvalue+time)”进行比较来完成的。-> 对于非现有用户，发送蜂蜜盐。

很难破解，但需要浏览器的 Javascript 客户端。

即使令人眼花缭乱，bcrypt 哈希每次都会用新的随机数和时间进行散列。

这个答案实际上很容易出错，所以我做了一个图表：

另外，请参阅此处为什么即使使用 SSL 也要添加这个额外的层：https ://blogs.msdn.microsoft.com/vbertocci/2005/04/25/end-to-end-security-or-why-you-shouldnt-驾驶你的摩托车裸体/