Home/ Questions/Q 6638963
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T23:29:55+00:00

I am writing my first application to use OAuth. This is for a desktop

  • 0

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?

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

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

EDIT2: 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    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?

    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.

    Your alternatives are:

    • 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.)

    • 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.

    And ignoring the fact that argument by analogy is unsound, this particular analogy breaks down for the following reason. Physical locks are not impenetrable. The lock on your front door “works” because someone has to stand in front of your house visible from the road fiddling with your lock for a minute or so … or banging it with a big hammer. Someone doing that is taking the risk that he / she will be observed, and the police will be called. Bank vaults “work” because the time required to penetrate them is a number of hours, and there are other alarms, security guards, etc. And so on. By contrast, a hacker can spend minutes, hours, even days trying to break your technical protection measures with effectively zero risk of being observed / detected doing it.

    • 0