如何保护 OAuth 密钥免受用户反编译我的项目的影响? [英] How do I protect OAuth keys from a user decompiling my project?

问题描述

我正在编写我的第一个使用 OAuth 的应用程序.这是针对桌面应用程序，而不是网站或移动设备，因为访问二进制文件会更困难，因此我担心如何保护我的应用程序密钥和机密.我觉得查看编译文件并找到存储密钥的字符串会很简单.

I am writing my first application to use OAuth. This is for a desktop application, not a website or a mobile device where it would be more difficult to access the binary, so I am concerned on how to protect my application key and secret. I feel it would be trivial to look at the complied file and find the string that stores the key.

我是反应过度还是这是桌面应用程序的真正问题(具有已知的解决方案)?

Am I over reacting or is this a genuine problem (with a known solution) for desktop apps?

这个项目是用 Java 编码的，但我也是一名 C# 开发人员，所以任何 .NET 解决方案也将不胜感激.

This project is being coded in Java but I am also a C# developer so any solutions for .NET would be appreciated too.

我知道没有完美的解决方案，我只是在寻找缓解解决方案.

I know there is no perfect solution, I am just looking for mitigating solutions.

我知道几乎唯一的解决方案是使用某种形式的混淆.是否有任何免费的 .NET 和 Java 提供程序可以进行字符串混淆?

I know pretty much only solution is use some form of obfuscation. Are there any free providers for .NET and Java that will do string obfuscation?

推荐答案

保护嵌入在不受信任的用户可以访问的二进制文件中的密钥没有什么好方法，甚至没有好方法.

There is no good or even half good way to protect keys embedded in a binary that untrusted users can access.

有理由至少付出最少的努力来保护自己.

There are reasons to at least put a minimum amount of effort to protect yourself.

最小的努力不会有效.即使是最大的努力，对于只有几个小时的空闲时间的熟练逆向工程师/黑客也无效.

The minimum amount of effort won't be effective. Even the maximum amount of effort won't be effective against a skilled reverse engineer / hacker with just a few hours of spare time.

如果您不希望您的 OAuth 密钥被黑客入侵，请不要将它们放入您分发给不受信任的用户的代码中.期间.

If you don't want your OAuth keys to be hacked, don't put them in code that you distribute to untrusted users. Period.

我是反应过度还是这是桌面应用程序的真正问题(具有已知的解决方案)?

Am I over reacting or is this a genuine problem (with a known solution) for desktop apps?

这是一个没有已知(有效)解决方案的真正问题.不是 Java，不是 C#，不是 Perl，不是 C，不是任何东西.把它想象成一条物理定律.

It is a genuine problem with no known (effective) solution. Not in Java, not in C#, not in Perl, not in C, not in anything. Think of it as if it was a Law of Physics.

您的选择是:

• 强制您的用户使用只会执行加密签名代码的可信平台.(提示:这对您的应用程序来说很可能不切实际，因为当前一代 PC 不能以这种方式工作.如果使用合适的设备，甚至 TPS 也可能被黑客入侵.)

• Force your users to use a trusted platform that will only execute crypto signed code. (Hint: this is most likely not practical for your application because current generation PC's don't work this way. And even TPS can be hacked given the right equipment.)

将您的应用程序转换为服务，并在您控制访问的一台/多台机器上运行它.(提示:听起来 OAuth 2.0 可能会取消此要求.)

Turn your application into a service and run it on a machine / machines that you control access to. (Hint: it sounds like OAuth 2.0 might remove this requirement.)

使用一些不需要分发永久密钥的身份验证机制.

Use some authentication mechanism that doesn't require permanent secret keys to be distributed.

让您的用户签署具有法律约束力的合同，不得对您的代码进行逆向工程，并在他们违反合同时起诉他们.弄清楚您的哪些用户入侵了您的密钥由您自己想象……(提示:这不会阻止黑客入侵，但如果黑客拥有资产，您可以收回损失.)

Get your users to sign a legally binding contract to not reverse engineer your code, and sue them if they violate the contract. Figuring out which of your users has hacked your keys is left to your imagination ... (Hint: this won't stop hacking, but may allow you to recover damages, if the hacker has assets.)

顺便说一下，类比论证是一种巧妙的修辞技巧，但在逻辑上并不合理.观察到前门上的物理锁可以阻止人们(在某种程度上)窃取您的东西，没有任何内容说明在可执行文件中安全嵌入私人信息的技术可行性.

By the way, argument by analogy is a clever rhetorical trick, but it is not logically sound. The observation that physical locks on front doors stop people stealing your stuff (to some degree) says nothing whatsoever about the technical feasibility of safely embedding private information in executables.

_{忽略类比论证是不合理的这一事实，这个特殊的类比由于以下原因而失效.物理锁不是不可穿透的.您前门上的锁有效"，因为必须有人站在您的房子前面，从路上可以看到他摆弄您的锁一分钟左右……或者用大锤敲打它.这样做的人冒着他/她会被观察到的风险，并会打电话给警察.银行金库工作"，因为穿透它们所需的时间是几个小时，还有其他警报器、保安人员等等.相比之下，黑客可能会花费数分钟、数小时甚至数天的时间来试图破坏您的技术保护措施，而这样做的风险实际上为零.}

这篇关于如何保护 OAuth 密钥免受用户反编译我的项目的影响?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！