I need some ideas on how to protect a private API key in an application, specifically in a c# .NET application.

Firstly, I understand that it is theoretically impossible to hide anything in the source code, so I came up with another idea, but I'm not sure how plausible it is. Anyway, would it be possible to somehow communicate with a web server to verify the private key and then talk back to the application to confirm that it is a legitimate handshake?

I'm have two keys to work with: a public key (as the name suggests, it doesn't have to be treated with the same care as the private), and a private key, which needs to be kept secure from others.

Any ideas on how I could do this would be greatly appreciated.

  • 4
    Are you trying to prevent someone who has access to a deployed binary application from reading the key (as your title implies), or protect them from modifying it (as your idea of verifying via server implies)? What is the ultimate end goal?
    – gregmac
    Commented Feb 5, 2014 at 3:09
  • 3
    It may be beneficial to outline the concept of of an API key for readers unfamiliar with it. An API key is a secret awarded to the developer of some software interacting with a service (typically a web service). It is used to identify the source of traffic, lift restrictions vs. anonymous accesses, and to bill the owner of the key for service usage. You are expected to keep it moderately hidden and preferably revoke it if it's compromised. As it needs to be communicated in full to the service, you always lose. Commented Feb 5, 2014 at 11:46
  • @gregmac Yes, I'm trying to prevent third party users of the application from reading the key.
    – Spencer
    Commented Feb 5, 2014 at 14:56
  • 1
    Don't put it there
    – CodeART
    Commented Feb 5, 2014 at 18:32

2 Answers 2


To summarize:

  • You have an API key issued to you by a vendor so you can use their API, and you have an obligation to prevent this key from being known by anyone else
  • You are making calls to that vendor's API (which require the API key) in your application code
  • You are deploying the application to systems where customers have access to the binaries and thus could potentially decompile/deobfuscate the code or intercept traffic

The best way to prevent compromise of this key is to keep control of it. This means it should never be deployed on a server where anyone besides you could read the binary, and never go over a communication link you don't control.

Ultimately, if the binaries are out of your control, everything in them is out of your control. Likewise, if someone can intercept traffic, they can capture the API key (potentially even if you're using SSL).

I can see two primary ways to accomplish this, both of which don't include your private API key in your deployed application:

Get a unique API key for each deployment

This would require some additional relationship with the vendor, where you can obtain keys or have your customers obtain keys.

This is actually quite common with, for example, products that use Google Maps API. The creator of the software has their own key they use while developing/running their copy, but they do not include it in the software, and instead, require you, as the user installing said software, to go to Google and obtain your own API key. The software merely has a configuration option to set the Google Maps API key to use.

In fact, many vendors that issue API keys contractually require you do things this way, so you may even be off on the wrong path anyway, and this may be the only solution you're allowed to use according to the vendor's Terms of Service and/or any legal contracts you may have with them.

Use a Proxy

Set up a proxy API, where your application calls your API (on your servers), and in turn, your API calls the vendor's API using the key.

You may need additional protection on your API, eg, something to ensure only your application is using it. This could be done by:

  • making the functionality so specific nothing but your app can use it
  • IP whitelists
  • Some existing licensing/authorization mechanism you already have for your servers
  • Your own API key system where you can issue keys to your customers

The thing to keep in mind here is that you may not be allowed to do this. Your vendor may have Terms of Service or legal contracts that prevent you from building an "aggregation service" or proxy, so you need to check with that.

Handling Misbehaviour

Even if your key doesn't get compromised, if one of your customers is doing something that causes the vendor to block your key, suddenly ALL your customers are disabled, and your only fix is to update everybody else.

Similarly, if you want to block one of your customers (eg, they stopped paying, have pirated the software, etc) then you can't do it without issuing an update to everybody else, and then disabling the key.

The logistics of this for anything beyond a handful of clients will quickly becoming untenable.

Whether you act as a proxy or have a unique key for each installation, you can handle any of these situations relatively easily (and with little to no impact to anyone else).

Trying to protect the key while it's embedded in your software is ultimately a futile effort. No matter what you do, any attacker that has access to the binaries, source, and/or communications channel and is determined enough to get at they key will be able to do so.

So don't embed it. "The only winning move is not to play."

  • 2
    +1 for "Get a unique API key for each deployment." Could even be used in conjunction with the proxy, giving you a [limited] ability to disable naughty keys/clients.
    – svidgen
    Commented Feb 5, 2014 at 18:06
  • @svidgen Very good point, I added a section discussing that. Thanks.
    – gregmac
    Commented Feb 5, 2014 at 18:15
  • 1
    +1, a universal key will almost invariably bite you in the *** Commented Feb 5, 2014 at 18:35
  • Very in-depth response. Unfortunately, I am only assigned one private API key so asking the user to fetch a key is not possible, as I am under NDA with the network protocols, thus the reason for a private key. The proxy is probably also out the the question. I may just have to resort to somehow turning it into a non-human readable format and putting it somewhere in the source - not a great option, but there's not many options left.
    – Spencer
    Commented Feb 5, 2014 at 23:55
  • @Spencer "The proxy is probably also out the the question" Why? That seems absurd, and distributing the key will also likely violate your NDA.
    – Andy
    Commented Mar 21, 2020 at 19:11

If you have a key in the object code, it is public by definition. There are hacks around obfuscators that quickly decompile object code. A private key would be outside the object code and in another file. The hard part is providing this private key to the user. Once it is provided, you can use a signature of the private key, tacked onto the end of the file, and a public key within the application, to verify the integrity of the private key. A web server can also do this verification, if you have a secure communication channel.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.