0

Numerous other questions on S.E ask exactly this same question.

Some of the highest rated questions are closed as Opinion Based, eg Best practice for storing and protecting private API keys in applications

Some best practices are published here: https://support.google.com/googleapi/answer/6310037?hl=en

In summary:

  1. Do not embed API keys directly in code
  2. Do not store API keys in files inside your application's source tree
  3. Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
    (This is not possible if you do not know where the client running on a mobile app will be connecting from using the keys)
  4. Restrict your API keys to be usable only for certain APIs
    (When you are not the creator of the API this is not possible)
  5. Delete unneeded API keys
  6. Regenerate your API keys periodically
    (Nr 5 and 6 is also not practical for Mobile applications, unless you force the user to Update the app every few days.)

If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.

Relying on obfuscation such as ProGuard or DexGuard does not void #1 or #2 above, so how does one solve this issue?

The Tahaan
  • 4,321
  • 1
  • 21
  • 39

2 Answers2

0

TL/DR: You don't.

Long answer:

Any key that is distributed with the app can be read by the app for it to use it. The app therefore has what it needs to read the key, even if it is encrypted or obfuscated. An attacker can use the same technique that the app would use, to obtain the key.

Equally, fetching the key form an external source does not protect it. Again an attacker can use the same channel to obtain a copy of the key.

Besides attacking the channel by which the app obtains the key (from an encrypted store inside the package, or from an external source), an attacker can also obtain it from the app's memory or by intercepting network transmissions.

The only secure solution is to never have a copy of the key on the end user device.

The key should be kept on a well secured server which will act as a middle-man between the user's device and the end service. Any requests by the client device to the end service needs to be routed via this server.

The server, having the "global project keys", should make the requests to the end service on the behalf of the end user, and return the result (and never any keys) to the client. For the client to use this server, a per-user authenticated session must be used. The server must validate this session for every request prior to forwarding the request on to the end service.

Summary:

Use a secure server between the client and the end service to make requests on behalf of clients using the global key.

EDIT: Side note: There is a distinction that needs to be made between per-user keys and keys that are project-wide. It is acceptable to keep keys that are specific to one individual person on that user's device.

The Tahaan
  • 4,321
  • 1
  • 21
  • 39
0

Hide that API Key

Relying on obfuscation such as ProGuard or DexGuard does not void #1 or #2 above, so how does one solve this issue?

While ProGuard or DexGuard don't solve the issue they will make it harder, by renaming the name that the API keys is associated with, while if the API key is hidden in native C code the string of it will not be associated with any reference when performing static binary analysis, therefore making it more difficult to extract as I show in my article How to Extract an API key from a Mobile App with Static Binary Analysis:

The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.

During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.

While this solution makes it very difficult to extract the API key with binary analysis, doesn't make it impossible, but easier approaches exist to extract the API key, like by doing a MitM attack as I demo in my article Steal that Api Key with a Man in the Middle Attack:

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.

So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.

An instrumentation Framework can also be used in conjunction with the MitM attack to bypass certificate pinning when the mobile app is using it. A popular one is Frida:

Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.

Reverse Proxy Server

If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.

Another common approach to solve the issue of storing API keys in the mobile app code is to delegate the responsibility for accessing Third Party APIs to a Reverse Proxy like I wrote in the article Using a Reverse Proxy to Protect Third Party APIs:

In this article you will start by learning what Third Party APIs are, and why you shouldn’t access them directly from within your mobile app. Next you will learn what a Reverse Proxy is, followed by when and why you should use it to protect the access to the Third Party APIs used in your mobile app.

Now, this only shifts the issue from protecting the API key for the third party service, like the stock trading API, to protect the API key or any other secret/identifier used to access the Reverse Proxy, but with the advantage that you now have control of how the third party API can be accessed, while keeping the API key to access it out of reach of the mobile app attacker.

Using user authentication to protect access to the Reverse Proxy will limit the scope of the attack, but will not eliminate it, because the Reverse Proxy server needs to be able to distinguish the who from what is doing the request, and in my experience I have seen that developers of any seniority are not often aware of this difference or have a misconception about it.

The Difference Between WHO and WHAT is Accessing the API Server

I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your backend, be it an API server or a Reverse Proxy server. I will extract here the main takes aways from it:

The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

So think about the who as the user the Reverse Proxy server will be able to Authenticate and Authorize access to the third party service(stock trading API in your example), and think about the what as the software making that request in behalf of the user.

Hardening the Reverse Proxy Server

If we pay attention to those best practices it gives Don't but no clear Do's for Mobile apps that need access to, for example, a stock trading API.

The Reverse Proxy server can be equipped with User Behavior Analytics(UBA) solutions to give it the ability to distinguish from who vs what is doing the request, but this will be done in a best effort basis, based on historical data used by the Artificial Intelligence algorithm to score the probability of being a human or not doing the request, aka the who.

While UBA solutions will reduce significantly the attack surface, it's still a negative identification model, due to the occurrence of false negatives and positives, and will require constant monitoring of the policies/rules being used by the algorithm to strike the best balance between not blocking too many legit users and not letting too many attacks pass by.

A positive identification model can be used instead, by employing the Mobile App Attestation concept as I recommend in this answer I gave to the question How to secure an API REST for mobile app?, on the section A Possible Better Solution.

So, the Mobile App Attestion in a nutshell can be described as a solution that will be able to lock-down, with a very high degree of confidence, the Reverse Proxy server with the mobile app, because the Reverse Proxy server will now be able to only accept requests from what it expects, aka genuine and untampered versions of the mobile app.

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

Exadra37
  • 5,511
  • 1
  • 20
  • 34