我应该混淆 Android 应用程序存储的 OAuth 消费者秘密吗？

Posted 2023-02-19

【中文标题】我应该混淆 Android 应用程序存储的 OAuth 消费者秘密吗？

【英文标题】：Should I obfuscate OAuth consumer secret stored by Android app?

【发布时间】：2011-10-30 14:53:54

【问题描述】：

我的 android 应用程序包含 Twitter API 的 OAuth 使用者密码。目前它以纯文本形式存在于.properties 文件中，因此有人在 APK 中查找它是零努力的。

我是否应该采取措施来隐藏它（例如，rot13 或存储在混淆的 Java 代码中）？还是我应该避免这样做，因为它会产生虚假的安全感？

人们通常如何在 Android 应用中分发/存储 OAuth 机密？ 秘密被窃取和滥用的情况有多普遍？

【问题讨论】：

我的 ios 应用程序和后端的 NodeJS+ExpressJS+PassportJS 具有相同的策略。我使用 Twitter 反向身份验证来验证来自 iOS 的用户。但是为了保护这一点并阻止用户在中间嗅探 HTTP 数据包以找出标头中的内容，我计划在我的服务器上使用 HTTPS 来加密数据。勾选此项以避免在您的应用中嵌入您的密钥：dev.twitter.com/docs/ios/using-reverse-auth

注意：反向认证仅适用于iOS

【参考方案1】：

要在 Android 应用中隐藏 OAuth 密钥，您可以使用我们开发的 gradle 插件。它是 Dexguard 的免费开源替代品。我们的 hidden-secrets-gradle-plugin 使用 NDK 和 XOR 运算符来混淆密钥以防止逆向工程。

您可以选择提供自定义编码/解码算法来提高密钥的安全性。

访问插件和所有详细信息：https://github.com/klaxit/hidden-secrets-gradle-plugin

【参考方案2】：

真正的问题是攻击者通过窃取它会得到什么......

您应该尽最大努力保护机密，但最终，一个积极主动的黑客总能在已安装的应用中找到它。所以这是秘密的价值与提取的难度。

客户端密码的值是模拟应用程序。它不提供对用户数据的任何访问权限。但是，由于 Twitter 支持向以前批准的应用程序自动颁发凭据（他们使用 Twitter 流程​​登录），因此攻击者可能会使用您的秘密构建 Web 应用程序并使用盲重定向窃取用户数据。

Twitter 实施的问题在于他们没有向开发人员询问应用程序的性质。如果他们这样做了，他们一开始就不会向您发布秘密，并且会阻止任何人使用您的客户端凭据构建 Web 应用程序并从已经批准它的用户那里窃取数据。

混淆是一种选择，但也是一种较弱的选择。将密钥移至充当 API 代理的 Web 服务器是另一回事，但这只是将问题转移到其他地方，因为现在您的应用程序必须针对代理服务器进行身份验证。但是，如果您要求用户登录您的站点（可以通过 Web 视图使用 Twitter 登录），这种模式可能相当安全。这样一来，试图滥用您的代理的人将需要他们的用户在您的服务上开设帐户，这不是很吸引人。

简而言之，继续混淆它。它不疼。也考虑使用代理模式。也许让 Twitter 知道他们的安全策略“不太好”。

【讨论】：

感谢您的回答。我正在开发的应用程序不会成为备受瞩目的社交应用程序，从中发布推文是一个附带功能。所以我想我会进行一些混淆，但会跳过代理模式的附加复杂性。

很高兴看到知情人士加强了我的观点。虽然代理确实将问题转移到其他地方，但潜在的黑客必须编写一个特定的程序来滥用您的代理。实际上，他们只会从其他应用程序中获取消费者的秘密——毕竟有over a million third-party apps。

Twitter 应用程序中有一个回调 URL，这足以阻止黑客构建网络应用程序窃取数据吗？它必须是您在应用设置中设置的域，否则它不会授权您发送的任何内容。

@Eran 即使密钥已经使用复杂的算法进行了混淆，是否有任何东西可以阻止某人在设备上安装证书以欺骗它认为它正在与 Twitter 的 API 通信，所以它发送去混淆的密钥与请求一起，实际上它正在将去混淆的密钥发送到攻击者的服务器？如果是这样，这个证书练习是不是很简单，那么混淆密钥有什么意义呢？

有没有办法把它放在 iOS/Android 钥匙串里？

【参考方案3】：

我肯定会阅读其中一位 OAuth 作者 Eran Hammer-Lahav 的 this analysis，其中引用了另一位 article dissecting Twitter's OAuth secret problems。

我的建议是对密钥进行模糊处理，这样它就不会被轻易提取，并且您应该远离投机者和垃圾邮件发送者。

Hammer-Lahav 认为 OAuth 机密不应被撤销，而应仅用于收集统计信息。希望 Twitter 遵循这个建议。

【讨论】：

文章说“不要在已安装的应用程序中使用客户端机密”，而您的建议是相反...

@Graham 好点——我应该更清楚一点。如果 OP 计划继续，那么混淆 很重要。否则，我想您需要一个实现，其中密钥存储在远程服务器上，并且 Web 服务充当 OAuth 调用的代理。我不知道这种方法的最佳做法是什么。

【参考方案4】：

0Auth 的要点是您不会在设备上存储任何珍贵的敏感信息 - 因此可以在设备上存储秘密（比真实用户凭据好得多）。如果您的设备机密被盗，用户可以随时使访问无效，而无需更改其凭据

【讨论】：

是的，但是如果有人发现了您应用的消费者机密，他们可以假装是您的应用。您可以更改密钥和秘密，但您在该领域的所有安装都不能再发推文了。

没有办法向坚定的人隐藏您的应用程序中的某些内容（甚至在俄罗斯，OS 360 也被逆向工程并在机器代码中进行了修补）。即使有人冒充您的应用程序，用户仍然必须针对服务验证自己的身份 - 所以没有真正的妥协。

我认为这个答案混淆了消费者机密和 oauth 令牌。