Question 173901 in React native Question posted in
The official React Native documentation can be found here.

Keeping secrets in React Native mobile app

I feel a bit awkward to ask about that question but how do you typically store secrets in React Native mobile apps? As I understand secrets are shipped with the bundle to the store but then using reverse engineering malicious actor could retrieve it back? So how to store it safely? I’ve red that calling Lambda function and retrieving from there is one option. But how to enable trust with Lambda first (how to be sure that my mobile app calls Lambda and not someone else)?

Tags:

2

Answers


  1. 0

    I would say it depends on what you want to do.

    If you want to compare values for example you can hash your secret with asymmetric algorithm and the compare the hash, by this way nothing is store in clear in the app.

    Other solution is to use symmetric algorithm with secret key to hash and un-hash, by this way without the secret nobody can see the content of the string.
    But with this solution we arrive with the same problem, where to store the secret?

    You can look at crypto-js library for these two cases.

    Something I personally use are config libraries like Firebase config.
    It allows you to not store anything on the app.

    Login or Signup to reply.
  2. 0

    Reverse Engineering

    I feel a bit awkward to ask about that question but how do you typically store secrets in React Native mobile apps?

    Don’t feel awkward because this isn’t a trivial thing to do securely. In fact it’s a very complex task to achieve. In a nutshell, if you store secrets in the app binary, you are better as treating them as public, therefore not a secret any-more, because as you say a bad actor can reverse engineer your bundle and extract them:

    As I understand secrets are shipped with the bundle to the store but then using reverse engineering malicious actor could retrieve it back?

    Yes, they can and isn’t that difficult, because a lot of approaches exist, and open source tools are available to make executing them easy enough for non developers. For example, the MobSF open-source tool can be used for static reverse engineer a mobile app as shown in the 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.

    No matter which technique is used to hide the secret in a mobile app binary (code obfuscation, string obfuscation/encryption) an attacker with enough time, resources and knowledge will be able to retrieve it. If not with static binary analysis then with a runtime attack. For example, by performing MitM attack to intercept the API requests as I show on the article How to MitM Attack the API of an Android App:

    Performing a MitM attack against an HTTPS channel requires the capability for the attacker to be able to add the proxy server Certificate Authority (CA) into the Trust Store of the device running the mobile app and a popular approach is to manually upload the CA to the device, but this comes with some challenges, that may require to root the device and/or repackage the mobile app.

    An easier way exists, and in this article I will show how to use an Android Emulator with a writable file system that will allow us to install the proxy certificate directly into the system trusted store, without the need to root the emulator or make changes in the mobile app.

    Certificate pinning can be used to prevent MitM attacks, but unfortunately pinning can be bypassed by repackaging the app without the pinning implementation or by using Frida at runtime to bypass the check. For example, you can another article I wrote on How to Bypass Certificate Pinning with Frida on an Android App to learn how you can do it:

    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.

    While pinning makes it more difficult to extract a secret it doesn’t full-proof them from being retrieved by attackers.

    Possible Solutions

    I’ve red that calling Lambda function and retrieving from there is one option. But how to enable trust with Lambda first (how to be sure that my mobile app calls Lambda and not someone else)?

    You are close to one of the best options that is to in fact remove secrets from being shipped inside a mobile app, but then (as you already realised) you shift the problem to the backend.

    Now, the problem to solve is how will your backend know that what is making the API request is indeed a genuine instance of your mobile app, not a bot, an automated script or an attacker manually poking around your API server with a tool like Postman.

    In a nutshell if you want a secret retrieved from a backend (your lambda function) and have it delivered just-in-time of being used by your mobile app, then it’s required that the backend only delivers the same to genuine instances of your mobile app. This requires for the backend to be able to determine that the mobile app is not under attack, not running on a root or jail broken device, that isn’t attached to a debugger or running in an emulator. This is a lot of attack vectors to cover and requires the backend to have realtime visibility to the running mobile app environment.

    I will recommend you to read my accepted answer to the question How to use an API from my mobile app without someone stealing the token where the Runtime Secrets Protection seems your best option.

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search