OAuth 1.0a，两条腿：如何安全地存储客户端的凭据（密钥/秘密）？

Question

我是否正确地认为 OAuth 1.0a 凭据需要以明文形式存储在服务器上（或者以可以作为明文检索的方式）存储在服务器上，至少在进行 2 腿身份验证时？假设您使用的是 HTTPS 或其他 TLS，这不是比使用用户名和加盐 + 哈希密码安全性低得多吗？有没有一种方法可以存储这些凭据，以便安全漏洞不需要撤销所有凭据？

---

更详细地说：我正在实现一个 API，并希望使用 OAuth 1.0a 来保护它。未来可能会有许多不同的 API 客户端，但迄今为止唯一一个不需要敏感的用户数据，因此我计划使用“两条腿”OAuth。

据我了解，这意味着我为每个 API 客户端生成一个消费者密钥和一个共享密钥。对于每个 API 请求，客户端都会提供使用者密钥以及使用共享密钥生成的签名。秘密本身不是通过线路发送的，我绝对理解为什么这比直接发送用户名和密码更好。

然而，据我了解，消费者和提供者都必须显式存储消费者密钥和共享秘密（如果我错了，请纠正我），这似乎是一个主要的安全风险。如果攻击者破坏了包含消费者密钥和共享秘密的提供商的数据存储，则每个 API 客户端都将受到损害，重新保护系统的唯一方法就是撤销每个密钥。这与密码相反，密码（理想情况下）永远不会以可逆的方式存储在服务器上。如果您对密码进行加盐和散列处理，那么攻击者将无法仅通过破坏您的数据库来侵入任何帐户。

我所做的所有研究似乎只是通过说“像处理任何敏感数据一样保护凭证”来掩盖这个问题，但这似乎很荒谬。违规确实会发生，虽然它们可能会暴露敏感数据，但它们不应该允许攻击者冒充用户，对吗？

Answer 1

你是对的。然而，oAuth 允许您代表用户登录，因此目标服务器（您从中访问数据的服务器）需要信任您提供的令牌。

当您是用户键入的秘密的接收者时，密码散列是很好的选择（顺便说一句，这实际上是当 oAuth 向用户呈现登录/接受窗口以随后生成令牌时发生的情况）。这就是“明文”部分发生的地方（用户以明文形式输入密码）。

您需要有一个等效的机制，以便服务器能够识别您；oAuth 提供的是提供密码以外的东西的能力 - 一种有限的授权形式，用于代表他登录。如果泄漏，那么您需要使其无效。

您可以以或多或少复杂的方式存储这些秘密，最终您仍然需要向服务器提供“明文”版本（但是，该服务器可能会使用哈希来存储它以进行检查，因为它只需验证您以纯文本形式呈现的内容（经过哈希处理后）是否与它们存储的哈希相对应）