在通过 HTTPS 发送密码之前对其进行加密可能不会增加安全性。

想一想：发送方如何加密密码，接收方如何解密？
如果您使用对称算法，那么他们是如何协商密钥的？如果密钥内置在客户端中，任何对客户端进行逆向工程的人都可以访问它。
如果您使用非对称（即公钥）算法来加密密钥或协商对称算法的密钥……您所做的与 SSL/TLS 为您所做的相同。

只需使用最高可用版本的 TLS，以及您的服务器和客户端都可用的最长密钥。

仅出于完整性考虑：HTTPS 使用 SSL/TLS。它最初代表“HTTP over SSL”。现在 SSL 被发现存在漏洞，你应该使用它的继任者 TLS。

在服务器上，您对（密码 + 盐值）进行哈希处理。Stack Overflow's Definitive Guide to Form-Based Website Authentication 中有很多关于如何进行安全的基于 Web 的身份验证的信息。

概括 Frederics 的回答是，如果解决方案在凭证数据流中不使用端到端的 HTTPS，则可能需要在客户端加密密码。

不使用端到端 HTTPS 的一些原因是：

• HTTPS 在某些边缘服务器（例如负载平衡器或反向代理）处终止，边缘服务器和最终目标服务器之间使用纯 HTTP（Frederics 情况将是另一个例子）。
• 请求在其流程中的某个点保持静止，例如在用于负载均衡的消息队列中

在这种情况下，按照您的描述使用消息级加密可能是有意义的。

我已经看到客户提出这样的要求，他们被出售了密码端到端加密的概念。

设置如下：有一个专用服务器来验证密码和其他凭据，仅此而已。托管应用程序的服务器将身份验证委托给该专用服务器，并传递加密的凭据。

HTTPS 加密在应用程序服务器处停止，但加密的凭据在到达身份验证服务器之前仍受到保护。

现在我不确定这是否有意义，但正如我所说，我遇到过要求这样的客户。

通常，软件架构由前端、中间件（用于业务逻辑）和后端（例如数据库）组成，所有这些组件都处理密码。破坏了其中一个组件的攻击者将能够拦截密码。

一种缓解措施是加密密码。使用公钥加密可能会出现以下情况：

• 后端创建公钥和私钥
• 公钥将包含在用户输入密码的表单中
• 当用户提交表单时，JavaScript 代码使用公钥加密密码
• 前端收到加密的密码，将其发送给中间件，中间件将其发送给后端
• 只有后端可以解密

因此，破坏前端或中间件的攻击者无法看到明文密码。