我正在设置一个家庭 HTTP 服务器，它可以向/从不同的客户端（Android 和 iPhone 应用程序）发送和接收 JSON 数据。
我想只允许某些用户访问，并且我正在考虑使用简单的用户名/密码机制，因为设置客户端证书对于这个小项目来说似乎有点矫枉过正。
当然，我不能通过纯 HTTP 从客户端向服务器发送明确的密码，否则任何安装了 wireshark/tcpdump 的人都可以读取它。所以，我正在考虑以下机制：
这种配置有问题吗？密码应该是安全的，因为它是通过加密连接发送的。
是的，这是标准做法。如果有的话，做除此之外的任何事情都会提供最小的额外优势（并且在某些情况下可能会损害安全性）。只要您验证与正确服务器的有效 SSL 连接，密码就会在线上受到保护，并且只能由服务器读取。在发送密码之前，您不会通过伪装密码获得任何收益，因为服务器无法信任客户端。
无论如何，信息可能丢失的唯一方法是，如果 SSL 连接被破坏，并且 SSL 连接以某种方式被破坏，“伪装”令牌仍然是访问帐户所需的全部，因此保护起来没有好处密码进一步。（可以说，如果他们在多个帐户上使用相同的密码，它确实提供了轻微的保护，但如果他们这样做，他们一开始就没有特别的安全意识。）
正如 MyFreeWeb 所指出的，还有一些复杂的系统可以使用质询响应来确保密码由客户端持有，但这些系统非常复杂，根本没有被广泛使用。它们也仍然没有提供很多额外的优势，因为它们只保护密码不被主动黑客攻击的服务器泄露。
不必要。
您还需要确保以下几点：
您的站点受到保护，可防止跨站点请求伪造。使用同步令牌模式。
您的站点受到保护，免受会话固定攻击。登录时更改会话 ID。
如果使用会话 cookie，则您的整个站点都是 HTTPS，而不仅仅是登录 URL，并且您的会话 cookie 被标记为安全且仅限 http（无 JavaScript 访问）。http://yoursecuresite如果用户键入（在同一浏览器会话中），浏览器将发送未加密的会话 cookie 。
您正在使用最近的协议。SSL 1 和 2 坏了，3 也可能坏了。尝试使用 TLS 1.3。
您正在使用强密码。
您没有使用 HTTP 压缩 (GZip) 或 TLS 压缩。如果您的网站显示用户输入（如搜索输入），那么如果您使用压缩，我可以计算出您的 CSRF 令牌和银行帐号。
您的服务器不允许不安全的客户端重新协商。
您正在使用 2048 位 RSA 密钥（或 EC 密钥的等效密钥），并且没有其他人知道您的私钥。
您正在使用 HSTS，因此即使用户键入 http，浏览器也会直接访问 https
您正在使用完美的前向保密，因此即使您的私钥泄露，您的历史通信也是安全的
只要您验证证书的有效性，这完全没问题，并且一直都在完成。
大多数通常被认为是安全的网站都采用了您所描述的方法。或者换一种说法，您只是描述了已建立的行业标准。
我建议不要使用比您提到的方法更安全的方法。（bcrypt 是否比其他加盐散列更好或更差是我不会讨论的。只是不要使用比加盐散列更弱的东西。）
如果您想让自己的安全性高于既定的行业标准，则可以选择其他选项。但它需要在您的应用程序的所有领域付出巨大的努力才能使其物有所值。
可能更安全的密码验证领域包括：