我是否认为OAuth 1.0a凭证需要以明文形式（或以可以作为明文检索的方式）存储在服务器上，至少在进行双方式身份验证时？假设您使用的是HTTPS或其他TLS，使用用户名和salted +哈希密码的安全性是否低得多？有没有办法以这样的方式存储这些凭据，即安全漏洞不需要撤销每一个凭证？
更详细：我正在实现一个API，并希望使用OAuth 1.0a来保护它。未来可能会有许多不同的API客户端，但到目前为止唯一的客户端不需要敏感的用户数据，所以我打算使用“双腿”OAuth。
据我了解，这意味着我为每个API客户端生成一个使用者密钥和一个共享密钥。在每个API请求中，客户端都提供使用者密钥和使用共享密钥生成的签名。秘密本身不是通过网络发送的，我明白为什么这比直接发送用户名和密码更好。
但是，据我所知，消费者和提供者都必须明确地存储消费者密钥和共享秘密（如果我错了，请纠正我），这似乎是一个主要的安全风险。如果攻击者违反了包含使用者密钥和共享密钥的提供者数据存储，则每个API客户端都将受到攻击，重新保护系统的唯一方法是撤销每个密钥。这与密码形成对比，密码（理想情况下）从不以可逆的方式存储在服务器上。如果您正在对密码进行腌制和散列处理，那么攻击者就无法通过破坏您的数据库来侵入任何帐户。
我所做的所有研究似乎只是通过说“像使用任何敏感数据那样保护凭证”来掩盖这个问题，但这看起来很荒谬。确实发生了违规行为，虽然他们可能会暴露敏感数据但他们不应该允许攻击者冒充用户，对吗？
答案 0 :(得分：0)
你是对的。但是，oAuth允许您代表用户登录，因此目标服务器（您访问数据的服务器）需要信任您提供的令牌。
当你是用户键入的秘密的接收者时，密码哈希是很好的（顺便说一下，当oAuth向用户提供登录/接受窗口以生成后续令牌时，会发生什么？ ）。这就是＆＃34;明文＆＃34;部分发生（用户以明文输入密码）。
您需要具有等效机制，以便服务器识别您; oAuth提供的是提供除密码以外的其他内容的能力 - 用于代表他登录的有限授权。如果泄漏，则需要使其无效。
你可以用或多或少的方式存储这些秘密，在一天结束时你还需要提供明文＆＃34;版本t服务器（然而，该服务器可能使用哈希来存储它以用于检查目的，因为它只需要验证您在纯文本中呈现的内容，当哈希时，它们对应于它们存储的哈希）