Storing Api Keys Securely in Flutter or Sending Payment Details to my Server?

Question

I'm building a flutter app where I will be taking a users' card details and tokenizing them. Currently, the API key for my payment provider is in the client app. The reason for this is to prevent having to send the credit card details to my server and then sending them to the payment provider. All in the name of PCI compliance.

It is however, ubiquitously stated, that you never want to store any API Keys in the client app which I understand. The question is, what's the best way to go about this? My instincts say to move the API key to the server, and just send the card details once for the tokenization. However, is this making the road to PCI compliance harder?

Any guidance on this would be appreciated.

Thanks

Answer 1

you should implement a private/public key approach.. where server and client both have only one key so neither one or the other can do nothing if not paired.

or try to give a look to jwt token api validation

Answer 2

Three things can be done here.

1. Use RemoteConfig to store all your config infos. And, store it in Flutter Secure Storage. Con: RemoteConfig is only fetched on App start.

2. Authenticate user first using JWT Token, then send the required data for user in the token itself. Con: User must be authenticated first to receive data.

3. Authorize the user with permissions. So, that both authentication and authorization are handled and nothing needs to be done without a key.

The #3 is the apporach we are using now. Of, course you can also use OpenIDConnect protocols to bring apps, servers and clients under one ecosystem too.

In all of these cases, the one holding the physical device will always have access to your servers after authenticated. Make sure to check for device id during the access. In the end, user can still fake all of this except for authorized details.

Answer 3

Your Problem

It is however, ubiquitously stated, that you never want to store any API Keys in the client app which I understand. The question is, what's the best way to go about this? My instincts say to move the API key to the server, and just send the card details once for the tokenization.

Your instincts are correct, and I have wrote about the reasons why third-party secrets should be kept in a backend you can control, and you can read more in my 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.

However, is this making the road to PCI compliance harder?

I cannot help you here, because I am not versed in PCI compliance but my instinct says it will make it a lot harder, because your are now dealing with Personal Identifiable Information (PII) from you user in your backend.

Possible Solutions to your Problem

Any guidance on this would be appreciated.

Anything that is on the client side must be considered public, because they can be reverse engineered statically or dynamically at runtime, and guess what, I also wrote some articles on it.

Open source tools exist to make all this a lot easier and even possible to be done by non-developers as I show on my articles.

Let's start by learning how to extract the API key with static binary analysis:

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.

On this article the awesome MobSF tool was used to easily extract an API key from the binary, but if an attacker cannot extract it from the binary, because it was hidden in native C code or was provided via a remote configuration on App boot, then an attacker will probably use a MitM attack to extract the API key for you credit card provider, and yes I have an article to show you how its done:

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.

The next step on hardening your security against MitM attacks is to use certificate pinning, and I also have an article of mine on how to do it:

Securing HTTPS with Certificate Pinning :

In order to demonstrate how to use certificate pinning for protecting the https traffic between your mobile app and your API server, we will use the same Currency Converter Demo mobile app that I used in the previous article.

In this article we will learn what certificate pinning is, when to use it, how to implement it in an Android app, and how it can prevent a MitM attack.

On this article you will learn how to use the Mobile Certificate Pinning Generator free tool to easily generate your Android and iOS configurations.

Now, you have a mobile app secured against MitM attacks, but as everything in software you often find ways to get around, and unfortunately this isn't an exception, because certificate pinning can be bypassed in a device the attacker controls, and yes I can show you how to do it:

How to Bypass Certificate Pinning with Frida on an Android App :

Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.

Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.

Frida is a very powerful tool and when used by a skilled attacker it will allow him to even hook to your app code to extract any secret from it without the need to disable pinning to perform the MitM attack. The attacker only needs to figure out the name of the function that uses or retrieves the secret in order to hook on it at runtime and extract such secret. To find the name of the function the attacker will statically reverse the mobile app binary and read your source code, even if the code is obfuscated.

While certificate pinning can be bypassed it is an important security addition to your mobile app security, because it's increasing the level of defences an attacker needs to bypass and increasing the skills set required. Your mobile app must use as many security defences as possible, just like it was done in medieval castles.

Until now you saw how you can progressively enhance the security of your mobile app to make more difficult to extract the card provider API key, but you are still vulnerable to its extraction.

You now need to find a solution that allows you to detect MitM attacks, tampered binaries, Frida at runtime and that at the same time time can deliver a runtime secret to mobile apps that pass a mobile app attestation that guarantees with a very high degree of confidence that such threats are not present. Unfortunately I don't know any open-source project that can deliver all this features, but a commercial solution exists (I work there), and if you want to learn more about you can read the article:

Hands-on Mobile App and API Security - Runtime Secrets Protection

In a previous article we saw how to protect API keys by using Mobile App Attestation and delegating the API requests to a Proxy. This blog post will cover the situation where you can't delegate the API requests to the Proxy, but where you want to remove the API keys (secrets) from being hard-coded in your mobile app to mitigate against the use of static binary analysis and/or runtime instrumentation techniques to extract those secrets.

We will show how to have your secrets dynamically delivered to genuine and unmodified versions of your mobile app, that are not under attack, by using Mobile App Attestation to secure the just-in-time runtime secret delivery. We will demonstrate how to achieve this with the same Astropiks mobile app from the previous article. The app uses NASA's picture of the day API to retrieve images and descriptions, which requires a registered API key that will be initially hard-coded into the 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.