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

Question

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

androidsecurityoauthstorage

43

我的安卓应用程序包含使用Twitter API的OAuth消费者密钥。目前，它以明文形式在.properties文件中，因此某人可以零力量查找APK。

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

人们通常如何分发/存储Android应用程序中的OAuth密钥？秘钥被盗和滥用的情况有多常见？

- Pēteris Caune

我在我的iOS应用程序和后端NodeJS+ExpressJS+PassportJS上采用相同的策略。我使用Twitter反向认证来验证iOS用户。但是为了保护数据安全，防止用户在中间嗅探HTTP数据包以查找头部信息，我计划在服务器上使用HTTPS加密数据。请参考此链接，避免将您的秘钥嵌入到应用程序中：https://dev.twitter.com/docs/ios/using-reverse-auth - Maziyar

注意：Reverse Auth 仅适用于 iOS。 - Steve Tauber

4个回答

4

我肯定会阅读OAuth作者之一Eran Hammer-Lahav所写的这篇分析文章，其中引用了另一篇剖析Twitter OAuth安全问题的文章。

我的建议是混淆密钥，以使其不易被提取，并且您将免受骗子和垃圾邮件的侵害。

Hammer-Lahav认为OAuth密钥不应该被撤销，只应该用于收集统计数据。希望Twitter正在遵循这个建议。

- David Snabel-Caunt

2

文章中提到“不要在已安装的应用程序中使用客户端密钥”，而你的建议则是相反的... - user23743

@Graham 很好的观点 - 我应该再清晰一些。如果 OP 打算继续，那么混淆确实很重要。否则，我猜你需要一个实现，其中秘密存储在远程服务器上，Web 服务充当 OAuth 调用的代理。我不知道这种方法的最佳实践是什么。 - David Snabel-Caunt

0

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

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

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

- Ben-J

-3

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

- Konstantin Pribluda

如果有人找到了你的应用程序的消费者密钥，他们就可以冒充你的应用程序。你可以更改密钥和密钥，但是那么所有在现场安装的应用程序都无法再推特了。 - funkybro

没有办法从一个决心坚定的人手中隐藏应用程序内部的任何东西（即使OS 360在俄罗斯被反向工程和机器码修补）。即使有人假装成为您的应用程序，用户仍然必须对服务进行身份验证 - 因此在这里没有真正的妥协。 - Konstantin Pribluda

2

我认为这个答案把消费者密钥和OAuth令牌混淆了。 - David Snabel-Caunt

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eran Hammer · Accepted Answer

真正的问题是攻击者从窃取它中得到了什么... 尽管如此，在安装的应用程序中存在高度动机的黑客总是可以找到窃取它的方法，所以它的保护价值在于秘密内容的价值与提取难度之间的平衡。客户端密钥的价值在于模拟应用程序，而不会给予任何访问用户数据的权限。然而，由于 Twitter 支持自动发放凭据给先前已批准的应用程序（他们使用 Twitter 的登录流程），攻击者可能会使用您的密钥构建一个 Web 应用程序并通过盲目重定向窃取用户数据。Twitter 实现的问题在于他们没有询问开发人员关于应用程序性质的信息。如果有询问，他们一开始就不会向您发放密钥，并会阻止任何人使用您的客户端凭据构建 Web 应用程序并从已经批准的用户中窃取数据。混淆是一种选择，但很弱。将密钥移动到充当 API 代理的 Web 服务器上是另一种选择，但这只是将问题转移到其他地方，因为现在您的应用程序必须对代理服务器进行身份验证。然而，如果您要求用户登录您的网站（可以通过 Web 视图使用 Twitter 登录），则这种模式可能相当安全。这样，试图滥用您的代理的人需要让他们的用户在您的服务上开设帐户，这并不是非常吸引人。简而言之，继续混淆它，这没有坏处。考虑使用代理模式。也许可以让 Twitter 知道他们的安全策略“不太好”。