如何保护OAuth消费者的安全，以及当它被泄露时如何反应？

Question

这个问题是关于试图理解在Android这样的移动平台上实现oauth所涉及的安全风险。这里假设我们有一个Android应用程序，它在代码中嵌入了消费者密钥/秘密。

假设消费者的秘密已经被泄露，黑客已经掌握了它，这会有什么后果呢？

妥协的消费者秘密假设

泄露的消费者机密本身不会影响用户的安全，也不会影响用户正在与之交互的启用OAuth的提供商中存储的任何数据，我这样说对吗？数据本身不会被黑客攻破，也无法被黑客检索。

黑客需要获得一个有效的用户访问令牌，而这要难得多。

黑客能用泄露的消费者秘密做什么?

我说的以下几点也是正确的：

• 黑客可以设置/发布模仿我的应用程序的应用程序。
• 黑客可以吸引将通过OAuth流的用户，通过黑客OAuth舞蹈(使用泄露的消费者密钥/秘密)检索访问令牌。
• 用户可能认为他正在处理我的应用程序，因为他将在授权过程中看到熟悉的名称(消费者密钥) process.
• When消费者通过黑客发出请求，黑客可以轻松拦截访问令牌，并且结合消费者机密，现在可以代表我签署请求以访问我的资源。

最终用户影响

在假设

• 黑客使用我的消费者机密
• 设置了一个应用程序/站点，我的一个用户被骗授权访问该应用程序/站点

可能会发生以下情况：

• 终端用户可能注意到有可疑的事情正在发生，并通知服务提供商(例如:谷歌)恶意应用
• ，然后服务提供商可以撤销消费者密钥/密钥

OAuth消费者(我的应用程序)影响:

我的应用程序(包含消费者秘密)将需要更新，否则我的所有客户端将无法再授权我的应用程序代表他们的请求(因为我的消费者秘密将不再有效)。

委派所有OAuth流量

虽然可以通过中间key服务器委派大量OAuth交互(执行OAuth舞蹈并将访问令牌发送给用户)，但还必须代理所有服务交互，因为签名每个请求都需要消费者密钥/秘密。这是将消费者密钥/秘密保存在移动应用程序之外，并存储在中间way服务器上更安全的地方的唯一方法吗？

Alternatives

有没有替代这个代理的方法呢？有没有可能将消费者秘密存储在中间can服务器上，并具有某种机制，使Android应用程序(在市场上发布并正确签名)可以向中间can服务器发出安全请求，以获取消费者秘密并将其存储在应用程序内部？是否可以实现一种机制，使中间will服务器“知道”这是一个请求获取消费者秘密的官方android应用程序，并且中间will服务器只会将消费者秘密分发给那个特定的android应用程序？

Answer 1

总结：我只会承担风险，并在客户端应用程序中保留秘密。

代理服务器替代

你可以合理地缓解下面列出的问题并使代理工作的唯一方法是全力以赴-将处理第三方webservice上的资源的所有业务逻辑移动到您的代理服务器，并使客户端应用程序成为具有丰富UI的哑终端。这样，恶意应用程序能够让代理代表它执行的唯一操作将是您的业务逻辑合法需要的。

但现在，您遇到了一大堆其他问题，必须处理可靠性和可伸缩性。

长篇大论为什么简单的代理不能工作

有些人在遇到问题时会认为“我知道，我会添加我自己的代理服务器”，现在他们有两个问题。(向Jamie Zawinski道歉)

你的假设很大程度上是正确的。直到您开始考虑您自己的服务器时，它是保密并代理客户端应用程序的调用，还是尝试确定应用程序是否合法并将秘密提供给它。在这两种方法中，您仍然需要解决“此请求是否来自我编写的一段代码”的问题？

让我重复一遍-没有办法在网络上区分正在运行的特定软件。如果消息中的数据看起来是正确的，那么没有什么可以证明是另一个应用程序在发送消息。

归根结底，如果我正在编写一个恶意的应用程序，我并不关心我是否真的知道真正的秘密，只要我能让知道它的人替我做一件事。那么，如果你认为恶意应用程序可以将你的应用程序模拟到第三方OAuth服务器上，为什么你确定它不能将你的应用程序模拟到你的代理服务器上呢？

但是等等，还有更多。代理服务所在的域是您对客户端和OAuth提供程序的标识(正如OAuth提供程序向最终用户显示的那样)。如果一个恶意的应用程序可以让你的服务器做坏事，不仅你的密钥会被吊销，而且你的公共web身份也不再可信。

我将从显而易见的事情开始--没有办法在网络上区分正在运行的特定软件。如果消息中的数据看起来是正确的，那么没有什么可以证明是另一个应用程序在发送该消息。

因此，任何依赖于应用端存储的秘密的算法都可以被欺骗。OAuth的优势在于，它从不将用户的凭据提供给应用程序，而是给应用程序自己的临时凭据，用户可以在必要时撤销这些凭据。

当然，这里的弱点是，一个足够好的应用程序可以让用户信任它，而不是在它完成其邪恶行为之前撤销凭据。

然而，缓解这一问题的一种方法是谷歌使用3条腿的OAuth，而不是标准的2条腿。在3条腿的OAuth中，没有预先分配的秘密，但在每次身份验证时都会发出一个新的访问令牌秘密，以及每个访问令牌。虽然最终这会遭受相同的缺点，因为糟糕的应用程序可以从其进程中读取好应用程序的令牌秘密，但它确实导致用户每次需要新的访问令牌时都必须批准应用程序访问。

当然，这也意味着它会给用户带来更多的不便和烦恼。