12

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?

markus
  • 40,136
  • 23
  • 97
  • 142
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
  • It's a very good question and it is a problem. I don't know the answer unfortunately. – James Oct 01 '11 at 22:36
  • 2
    If you can put them in the binary, a hacker can get them out. – Andrew Thompson Oct 01 '11 at 22:37
  • 1
    That's only because there isn't really an answer. Here's an example of a list of Facebook API keys. http://www.reddit.com/r/reddit.com/comments/iscee/dont_post_to_facebook_from_gameboy_color_post – Daryl Teo Oct 01 '11 at 22:37
  • I've posted a solution that we felt worked *well enough* and in the real world, Well enough is the best you can achieve; it's a trade off between time spent to solve a problem and the likelihood of there being a problem. Smoke and mirrors :) – Russ Clarke Oct 02 '11 at 01:35

5 Answers5

14

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.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • There is a solution: the API provider should not issue a client secret to 'public clients' (per the OAuth 2.0 spec). It should use other techniques to mitigate the risks of allowing native applications. But as to the original question, no, there is no way to hide client credentials in a native application which is why the new spec is so explicit about it. – Eran Hammer Oct 02 '11 at 06:49
3

OAuth is not designed to be used in the situation you described, i.e. its purpose is not to authenticate a client device to a server or other device. It is designed to allow one server to delegate access to its resources to a user who has been authenticated by another server, which the first server trusts. The secrets involved are intended to be kept secure at the two servers.

I think you're trying to solve a different problem. If you're trying to find a way for the server to verify that it is only your client code that is accessing your server, you're up against a very big task.

David Pope
  • 6,457
  • 2
  • 35
  • 45
2

It doesn't matter the platform, what you are asking will always be impossible. Whatever you have done to need this feature is whats wrong with your application. You can never trust a client like this. Perhaps you are looking for (in)Security Through Obscurity.

markus
  • 40,136
  • 23
  • 97
  • 142
rook
  • 66,304
  • 38
  • 162
  • 239
  • 2
    I know it is a problem, that's why I posted my question. Please update your answer to mitigate the problem or please remove it, this is more of a comment than a answer. – Scott Chamberlain Oct 01 '11 at 22:44
  • @ScottChamberlain, it's not just a problem, it's impossible, as Rooks says. Any attempt to “mitigate” the problem could be overcome. – svick Oct 01 '11 at 23:04
  • @svick do you feel it is pointless to lock your door as a person could use a battering ram to break it down? There are reasons to at least put a minimum amount of effort to protect yourself. – Scott Chamberlain Oct 01 '11 at 23:09
  • @ScottChamberlain, this is more like giving a device to users and putting a lock on it so that they won't look inside. I think that lock is pretty much pointless. – svick Oct 01 '11 at 23:13
  • @Rook the application uses the Dropbox API, I can use the dropbox folder but their dev page specifically [says not to as that method will be deprecated soon](https://www.dropbox.com/developers/desktop_apps). – Scott Chamberlain Oct 01 '11 at 23:13
  • +1 - to counter unfair downvote. Don't downvote just because you are getting an answer that you don't want to hear. – Stephen C Oct 02 '11 at 01:07
  • @svick Impossible is such an ugly word. There *are* ways and means to deter all but the most inventive intruder. – Russ Clarke Oct 02 '11 at 01:33
  • 1
    @RussC - you increase the time from a few minutes to few hours for a semi-skilled hacker. If the keys are valuable, it would be unwise to assume that none of the users (or their friends) don't have the technical skill to extract them. – Stephen C Oct 02 '11 at 01:52
  • Agreed - but there is no way of stopping someone determined or knowledgeable enough, other then just not providing the data. You have to ask yourself, is what you're protecting worthwhile enough, if so - should you even be including it ? I don't agree with security by obscurity, but I do believe strongly in only giving up the minimum required information, my answer goes part way to solving that. – Russ Clarke Oct 02 '11 at 01:57
2

Edit: Let me be clear; this is not a solution for safely storing your keys in a binary, as many others have mentioned, there is no way of doing this. What I am describing is a method of mitigating some of the danger of doing so.

/Edit

This is only a partial solution, but it can work depending on your setup; it worked well for us in our university internal network.

The idea is that you make a service that is only likely to be accessed by a computer.

For example, an authenticated WCF service, that not only requires you to log in (using the credentials that are stored in your executable) but also requires you to pass a time dependant value (like one of the gadgets you get for your online banking) or a the value of a specific database row, or a number of options.

The idea is simple really, you cannot totally secure the credentials, but you can make them only part of the problem.

We did this for a windows app that uses a student data store, which as you can imagine, had to be pretty secure.

The idea was that we had a connection provider running as a service somewhere and we had a heartbeat system that generated a new key every 30 seconds or so.

The only way you could get the correct connection information was to authenticate with the connection provider and provide the current time-dependant heartbeat. It was complex enough so that a human couldn't sit there and open a connection by hand and provide the correct results, but was performant enough to work in our internal network.

Of course, someone could still disassemble your code, find your credentials, decipher your heartbeat and so on; but if someone is capable and prepared to go to those lengths, then then only way of securing your machine is unplugging it from the network!

Hope this inspires you to some sort of solution!

Russ Clarke
  • 17,511
  • 4
  • 41
  • 45
2

Eazfuscator.NET and other .NET obfuscators do string encryption, which makes slightly less trivial for someone to see your string literals in a de-obfuscation program like Reflector. I say slightly less trivial because the key used to encrypt the strings is still stored in your binary, so an attacker can still decrypt the strings quite easily (just need to find the key, and then determine which crypto algo is being used to encrypt the strings, and they have your string literals decrypted).

ogggre
  • 2,204
  • 1
  • 23
  • 19
Yoshi
  • 3,325
  • 1
  • 19
  • 24