假设您的意思是 TLS 而不是 SSL 本身（它更老且损坏），在 POST 请求中传输密码绝对没问题。这是标准的，几乎每个主要和安全的 Web 身份验证服务都是这样工作的。您只需确保正确配置了 TLS。TLS 减轻了您担心的所有攻击。它使用 HMAC（或类似的身份验证）来保证完整性，并减轻重放攻击、反射攻击和影响身份验证系统的类似问题。请注意，可能会发现需要升级 TLS 版本或手动缓解的新漏洞。SSL 实验室可以测试 TLS 实施中的已知漏洞。

HTTPS 有几个用途，可以防止重放攻击并为正在发送的消息提供机密性。为了维护这些保证，客户端当然必须正确验证来自服务器的 TLS 证书，即将证书与预期域匹配（或者如果您有自签名证书，则与指纹匹配）。否则，中间人攻击可能会在任何一方都没有注意到的情况下发生。这样，客户端就知道它确实在与正确的服务器通信。

但是服务器如何信任客户端呢？为此，您可以使用客户端证书，或者按照您的建议，使用 API 密钥。API 密钥是一个常见的概念，所以如果这样做有什么大问题，我们现在就会停止这样做。定期更新 API 密钥是一种很好的做法，并且拥有一个密钥 ID 字段以便能够轻松地轮换它们可能很方便，但通常多年使用相同的密钥应该不会有很大的风险——当然，它取决于信息的敏感性，有多少人可以访问密钥等。

我不同意通过 HTTPS 发送共享机密的安全性。

这是我的推理：

SSL/TLS 旨在防止有人在对话发生时破坏对话。因此，存在安装了弱密码的网络服务器。（不是每个人都能让他们的操作系统保持最新；我们中的一些人仍然必须支持可能无法更新的过时硬件）

使用较弱的密码，或@amcgregor 列出的一些缺陷，有人可能能够在消息发送几分钟后查看消息，这就是他们建议您使用时间戳来散列身份验证令牌的原因。

如果您在每条消息中都发送共享密钥，那么攻击者只需查看任何一条传入消息即可永久撤消您的安全性。（至少，在更改密码之前，让我们面对现实吧，除非他们采取措施提醒您，否则不会发生）

如果您使用更安全的方式（分配限时令牌的质询/响应），那么窥探方需要查看两个特定消息（质询和响应），并使用它来获取共享密钥的候选者，然后要么获得更多挑战/响应键来缩小范围，要么开始尝试所有候选人并给你他们攻击的迹象。

将您的共享秘密放在网络上，无论加密多么好，都意味着您依赖于单层安全性，实际上这是一个坏主意。