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
Three things can be done here.
Use RemoteConfig to store all your config infos. And, store it in Flutter Secure Storage. Con: RemoteConfig is only fetched on App start.
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.
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.
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.
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
I do have a background as a native iOS software developer.
We had a couple of apps for iPhones and iPads that used CloudKit to sync data between the same App installed on different devices of a single user.
It was used for simple things like favorited items within apps that did not have any login or account mechanisms.
How would I achieve such a functionality in flutter?
Havent found any iCloud related plugins for dart/flutter.
Thank you!
I do not believe there is a direct way to access the CloudKit from dart/flutter, however, there is nothing stopping you from trying this architecture.
Build a (PHP?)/CloudJS application on a webserver to serve REST-ful API calls that send/retrieve data from CloudKit Containers (CloudKit Web Service Reference). You'll want to set up some server-to-server authentication for this to work.
Posting/Fetching data via the REST API calls from dart/flutter. There are many libs that facilitate this and author (BRIJESH) over on androidkt.com offers an interesting walkthrough of some options.
I can't seem to find any documentation on how to access Google Cloud Storage using a service account from iOS. The iOS application writes images to Rails and I've used a service account with the ruby apis to save the image to Google Storage. I'm trying to read those images from iOS but it seems like the ability is not there and I'm not sure why. The only way I can make it work is to use an API key and set the predefinedAcl to 'publicRead'. This means my application's images are open to the internet.
What am I missing? Is there a reason this functionality isn't there in the iOS library? Any plans in the future?
Thanks
I think you are heavily compromising your security while following a really bad practice. Here's are two strategies on how to fix it:
When you save your images to Google Storage, you should create a signed URL for the same and use that as end point for clients/app. OR
Save original Google Storage URLs to user's account, inaccessible via user api, and during runtime when a request for image is received, generate a short duration based signed URL.
Service key based approach is really faulty as first you are giving away your project credentials and moreover you can never even expire those keys since they might be used in one of many end devices.
I'm able to upload files from iPhone using ASIHTTPRequest wrapper for an application which allows simple storage to my account. The question i'm concerned about is, could distributing the access keys along with the application be a good idea? what is the best way to deal with it in terms of security? are the keys i use sniffable via monitors over https? any suggestions over it will be appreciated.
I upload files to a server (using ASIHTTPRequest) and then from the server to an AWS account for this very reason. I can control the security on the server much easier than I can on devices. Plus, if I need to change the keys I can do it on the server very quickly.
This will add another layer to your application but I think it's well worth it.
You can also check out this post Architectural and design question about uploading photos from iPhone app and S3
We have a web application and we've built phone applications (iPhone, Android, BlackBerry) to be companions to the site. The usual workflow is that an existing user of the site gets a phone app and then plugs their existing credentials into the phone app and they are off and running, but more often now we are seeing folks who are downloading the app and then (and this should not surprise anyone) don't read the help screen that explains they need to go and get credentials at the web site and therefore cannot connect to the application which does require registration to manage their content. This is a giant usability fail condition.
So we know that we need to put user registration workflows on the phone app.
Other than the obvious solution of duplicating our registration page on the mobile, does anyone know of a better identity solution for the phone? For example, on the desktop we also use Facebook Connect as an identity server and the users love it. I'm looking for something that simple that we can implement across the major smartphone platforms.
Clarifying note:
I should add here that this registration mechanism is likely to; and it would be desirable if it did, go hand in hand with a general identity/authorization mechanism such as the Facebook mechanism mentioned below.
One other place I'm poking around is to see whether there's an openId solution that does not require a browser to pop up.
Restful service might be the e asiest way for you to achieve this, you can use it on any device that can make http requests, so you can make your own login screens and talk to the s ervice that way...
Facebook has a Connect API for the iPhone. Integrating it into your iPhone app is very smooth.
http://developers.facebook.com/connect_iphone.php
On the BlackBerry we were able to build a fairly robust REST pipeline between the client apps in the field and our servers. We primary use the framework for updates, but the device API is generic enough to be able to build almost anything you need via standard HTTP/HTTPS GET/POST calls.
On the RIM platform, look into the HttpConnection API as a starting point. There is also an example on the BlackBerry Developer's site which will help. Finally, I believe there are several examples inside the sample package that comes with every BlackBerry JDE (IDE + API download).