WSSE 身份验证悖论答案

【问题标题】：WSSE authentication paradoxWSSE 身份验证悖论
【发布时间】：2012-09-25 17:55:20
【问题描述】：

我目前正在研究 WSSE 协议以保护我的 api。

我已经理解了基础，并且在我的脑海中很清楚。

但是我遇到了一个问题。

假设我想生成一个一次性摘要，我必须连接时间戳、随机数和密码。

但是，在服务器端，我没有存储在数据库中的明文密码，所以我无法检查摘要。

不能切换到清除密码。

我不能向客户端提供用于哈希密码的算法，因为他们使用盐，而盐对客户端不可用。

我能想到的唯一解决方案是不对 Digest 进行哈希处理，只需将数据连接起来并使用 base64 进行处理。

这样我就可以对用户密码进行编码以检查其有效性。

由于密码以纯文本形式传输，可能不安全，但如果我强制 HTTPS 进行身份验证会怎样？

会安全吗？

【问题讨论】：

【解决方案1】：

由于密码以纯文本形式传输，可能不安全，但如果我强制 HTTPS 进行身份验证呢？

会安全吗？

是的，在正常范围内，这是确保其安全的唯一方法。

只需发送完整密码，但要通过安全性好的 TLS 连接发送。您可以使用 brypt 或 PBKDF2 等安全密钥派生函数，并输入存储的随机盐（每个用户一个）和密码来检索“哈希”，然后可以检查存储在数据库中的那个。

请注意，您不需要从客户端发送时间戳。当然，记录和限制身份验证尝试的次数是个好主意。您不能使用时间戳作为哈希的输入，每次时间戳更改时结果都会不同。

【讨论】：

你能告诉我更多关于“安全密钥派生”的信息吗？一件事是我不想让我的客户知道和使用我自己的算法，想象我的加密算法被泄露，我的客户将无法再使用它（主要是因为密钥已被泄露）。另一件事是，如果我以明文形式发送密码，我就无法防止重放攻击，对吗？（那么nonce和时间戳就没用了）
如果您使用 TLS，那么您已经受到保护，免受重放攻击（通过连接上的窃听者）。如果您让客户发送纯密码，那么您就不会将您的客户与任何东西联系起来。如果您不使用 TLS，那么您的选择非常有限，除非您的客户端实施专有协议来防止这种情况发生，否则您将无法轻松防止重放攻击（或密码泄露）。
好的，感谢您的澄清，使用 API 需要 HTTPS。顺便说一句，我想知道是否仍然需要 WSSE，或者我是否应该使用提供类似功能的 HTTP Basic。
如果您使用基于密码的安全性，您并不特别需要它。如果您希望它具有完全的 WSDL/SOAP 合规性，那就更成问题了。在这种情况下，我建议坚持 WSSE。另一个优点是，如果您需要消息层的安全性（与 TLS 可以提供的传输层安全性相比），您还可以启用 XML digsig。