C# API Key – Best Way to Hide in Source Code

apiauthenticationc

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.

Best Answer

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

Related Topic