5

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

更详细地说：我正在实现一个 API，并希望使用 OAuth 1.0a 来保护它。未来可能会有很多不同的 API 客户端，但目前唯一一个不需要敏感的用户数据，所以我计划使用“2-legged” OAuth。

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

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

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

4

1 回答 1

1

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

当您是用户键入的密钥的接收者时，密码哈希是很好的（顺便说一句，当 oAuth 向用户显示登录/接受窗口以在之后生成令牌时，实际上会发生这种情况）。这是“明文”部分发生的地方（用户以明文形式输入他的密码）。

你需要有一个等效的机制，以便服务器识别你；oAuth 提供的是提供密码以外的其他内容的能力 - 一种有限的授权表格，用于代表他登录。如果泄漏，则需要使其无效。

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

于 2015-04-13T08:33:43.240 回答