TALSEE Security Experts Working Group

TALSEE (Talsec Security Experts) is a working group supported by Talsec, consisting of external guest experts addressing practical mobile security and threat defense topics for the developer community.

Talsec Originals

Published by our engineers.

Flutter has gained significant traction within FinTech, underscoring the crucial need for robust security measures. The platform’s popularity attracts attention from both app developers and cybercriminals. Flutter’s strong security posture, evidenced by fewer reported vulnerabilities and CVEs, makes it a solid choice for developing sensitive apps.

Flutter CTO Report 2024 Download (PDF)

Flutter Built-in Security

Flutter is more resilient to decompilation than native apps. Its binary packaging offers better protection of code and hardcoded data, although the number of Flutter-specific reverse engineering tools is increasing rapidly, continually broadening the potential threat landscape (e.g., reFlutter, flutter-spy, blutter).

Common Vulnerabilities

Despite its advantages, Flutter apps are not immune to common vulnerabilities:

• Privileged Access Issues: Rooting and jailbreak concerns remain prevalent.

• Dynamic Attacks: Techniques such as hooking frameworks (e.g., Frida, Xposed) pose significant risks.

• App Cloning and Repackaging: Unauthorized duplication of apps is a persistent threat.

• TLS Pinning Bypass: Critical for defending against man-in-the-middle attacks.

• Session Hijacking and App Impersonation: Compromise user sessions and mimic legitimate apps.

• Malware: Leveraging app permissions (accessibility misuse, screen sharing, keyloggers, SMS OTP interceptors, etc.) for malicious activities.

Developer Awareness

Flutter developers must stay informed about security threats and evolving attack vectors across all supported platforms. This demands n-depth expertise and continuous learning, making app security a specialized area within software development.

Essential Security Hardening Measures

In the financial sector, regulators mandate the adoption of a range of security techniques, which can be categorized into three primary areas:

1. Runtime Application Self-Protection (RASP): Implement client-side measures to monitor and react to integrity and environment compromises.

2. API Protection: Safeguard against app impersonation using tools like Firebase App Check, attestation services, or API protection SDKs such as AppiCrypt.

3. Anti-Malware: Detects and mitigates risks posed by malicious apps on client devices.

Basic controls can often be implemented using freemium or community-supported tools. However, advanced enterprise-grade protection typically requires custom development or commercial security solutions.

Advances in Mobile Security Tools for Flutter

The proliferation of app-to-API end-to-end protection solutions (such as App Attestation, AppiCrypt, and AppCheck) is effectively countering the escalating threats from mobileoriented API abuse. These threats encompass App impersonation techniques such as botnets, password enumeration scripts, data scraping, promotional abuse, fake registrations, and phishing campaigns.

However, due to Flutter’s compiled nature, Static Application Security Testing (SAST) tools have not yet reached the level of sophistication seen in native applications. This presents a challenge in maintaining security parity with other platforms. Conversely, the advent of Software Bill of Materials (SBOM) analysis has simplified the examination of third-party dependencies, thus enhancing the thoroughness and effectiveness of security assessments.

Overall, while there are still areas needing improvement, the strides made in mobile security tools for Flutter demonstrate significant potential in safeguarding against complex and evolving threats.

Budget Considerations

App issuers should allocate 20% to 25% of development and maintenance budgets to security features. It’s crucial to recognize that due to the dynamic nature of attack vectors and operating system updates, ongoing maintenance costs for security features may be significantly higher than initially estimated.

Conclusion

Proactive security measures are not just beneficial but essential for app protection in today’s dynamic threat environment. Ensuring comprehensive security requires both strategic investment and dedicated expertise.

Written by Sergiy Yakymchuk (CEO at Talsec)

Talos, a remarkable figure in Greek mythology, was a giant bronze automaton, crafted either by Hephaestus or Daedalus. His sole duty was to protect the island of Crete, tirelessly patrolling its shores. Circling the island three times a day, Talos would hurl stones at approaching ships to fend off intruders, symbolizing unwavering vigilance and defense.

In essence, Talos embodies constant protection — just like Talsec’s approach to security.

Happy Cybersecurity Month — stay vigilant, stay secure!

Introduction

Imagine you are developing a sales application for a local store. To expedite the purchasing process, the company decides to store users’ credit card data for future transactions. This data will be stored locally on the users’ devices. The crucial question that arises is: how and where to securely store this sensitive data? The answer to this question is what has led us to write this article.

To illustrate the importance of proper storage practices, let’s consider that you developed the feature without adhering to best practices, which led to the leakage of your customers’ credit card data, resulting in the loss of their trust and some lawsuits. Although this is a undesirable scenario, it could become a reality.

In this context, we will explore security concepts related to data storage and present the best practices for managing each available storage method, ensuring that users’ information remains protected against potential threats and vulnerabilities.

Understanding Data Storage Security Concepts

What defines secure data? Basically, it is information protected against unauthorized access, theft, corruption, and destruction outside the application’s expected lifecycle.

Although this definition brings with it a huge challenge, this subject has been debated for a long time in computing, and thanks to that, we currently have some concepts that help us better understand how to achieve this security. For this article, I would like to focus on three.

First, we have encryption, which transforms readable information into protected formats, ensuring that only authorized recipients can access and understand the data. Next, we have access controls, which allow applications to manage who is authorized to access the data and how this will occur. This control can be implemented through various components, such as: authentication, authorization, networking, management, and auditing. Finally, there are hardware-based security solutions, which use physical technologies to protect against attacks. This is possible thanks to execution in an isolated hardware environment, which takes place in a secure area within the main processor. A similar process can be done with the Trusted Execution Environment (TEE), or in a dedicated coprocessor, as happens with Apple’s devices that have the so-called Secure Enclave. These concepts will be further explored throughout the article.

Insecure Storage Methods

Now that we understand what makes data insecure as well as some of the concepts behind data security, let’s take a look at the methods offered to developers that, by default, have a lower level of security and can be considered insecure.

File Storage

In both operating systems, Android and iOS, applications can create and store files in the internal file system, even though this access is not exposed to the end user in the same way as in desktop systems. Each application has a dedicated storage space, which provides a certain level of isolation between the data of different applications.

The data best suited for this type of storage includes documents, images, and other larger files. For example, video streaming applications often offer the option to download content so that the user can watch offline. These would be excellent candidates for utilizing this storage method.

UserDefaults and SharedPreferences

Another method for storing small amounts of data is by using UserDefaults on iOS and SharedPreferences on Android. Both were developed to store simple data using key-value pairs, consisting of a key of type String and a value limited to the types supported by each platform.

These systems are ideal for saving user preferences, application settings, and other non-sensitive data that needs to persist between sessions. For example, it is common to store the theme selected by the user, the last accessed tab, or configuration options.

Why are they considered insecure?

In the previously presented storage methods, data is not encrypted by default. This makes it easier to access information on devices with root or jailbreak access, increasing the risk of exposing users’ sensitive data. On non-rooted or non-jailbroken devices, access to the file system is restricted to protect sensitive system files and application data for security purposes. Root or jailbreak permissions allow us to bypass these restrictions and gain full access to these files.

To illustrate the vulnerability of applications to modified devices, I will extract and modify content within a counting application developed with Flutter. In this example, the value of the last count is stored in a text file. It’s important to note that this lack of security is not specific to Flutter — the same issue would occur if the application were developed natively for Android.

For our experiment, it will be necessary to use an emulator with root permissions and the Total Commander application — This will help us access the Android file system. However, it’s worth mentioning that Total Commander is just one of many tools that can be used for this purpose.

The first step is to access our application and add some numbers to the counter. In this way, the application will write and store the count value in a text file.

Next, we will open Total Commander. We will navigate to the data/data/ directory and access the folder named Installed apps. After that, simply locate the counting application we developed.

With that, we will have access to the internal files of our application. To view the created text file, just navigate to app_flutter/counter.txt.

In this way, we can view all the content stored in this file and, in addition, we have the possibility to modify the value as desired. If we change the value, it will be necessary to save the file and reopen the counting application. After this procedure, the modified value will be displayed in the application.

Secure Storage Methods

Although we have already discussed data insecurity at length, we have also covered essential fundamentals such as encryption, access control, and hardware-based security solutions. In this section, we will explore storage methods that use these fundamentals to ensure greater data security. However, before we move forward with the content, it will be important to review in more detail the concept of hardware-based security, as this will be crucial to understanding what happens under the hood.

Hardware-based Security solutions

For software to maintain its security, it must rely on hardware that is designed with robust security features. For this reason, Both Android and iOS devices have their own hardware-based security technologies.

In most cases, Android and iOS implement different Hardware-based security solutions. However, they always follow the same principle: creating an environment isolated from the operating system that is secure for performing cryptographic operations. ⁤⁤This ensures that even if the main processor is compromised, critical information, such as cryptographic keys and authentication data, like biometric data, remains protected. ⁤

On Android, the primary mechanism is the Trusted Execution Environment (TEE), an isolated area within the main processor. However, more recent models are also integrating the Secure Element (SE), a chip separate from the processor and specifically designed for enhanced security.

On iOS, although the Secure Element exists, it is more related to Apple Pay technologies. The primary focus for developers is the Secure Enclave. This hardware component is integrated into the main processor and acts as a coprocessor exclusively focused on security.

⁤I know, all this talk about hardware may seem distant from our reality as app developers. ⁤⁤However, have you ever heard of Android's KeyStore or Apple's Keychain?

Platform-Specific Secure Storage Options

Tools like the Android's KeyStore and the Apple's Keychain bridge the gap between complex security-dedicated hardware and everyday development. However, these tools differ in how they operate.

The KeyStore present on Android devices is responsible for ensuring the security of the cryptographic keys used. It also allows developers to restrict when and how the keys can be used by applying access control concepts, such as requiring authentication before the data is utilized. As mentioned, the KeyStore system integrates directly with security hardware components to ensure that cryptographic keys are generated, stored, and handled in a secure and isolated environment.

While the KeyStore was designed to store cryptographic keys used by applications, Apple's Keychain is more comprehensive, also handling passwords and other small but sensitive data, such as keys and login tokens. Due to this wider scope, the requirements—and consequently the implementation—differ. The Keychain is implemented using an SQLite database stored in the file system. The security of the stored data is guaranteed by encryption, whose key is stored in the Secure Enclave, ensuring protection through both encryption and dedicated hardware. Additionally, access control policies can be applied to the data, further reinforcing security.

Transitioning to Secure Data Storage

After all this overview on data security in mobile applications, it’s time to show in practice how we can improve the security of the data we store.

Remember the counting app we highlighted at the beginning of the article? Using this, we will demonstrate a step-by-step guide on how to apply the concepts we presented throughout the article.

Cryptography

As mentioned, encrypting is transforming readable information into protected formats. But how does this actually happen? The explanation depends on the type of cryptography: it can be symmetric or asymmetric. In the tutorial below I will only be focusing on symmetric algorithms, if you are curious about asymmetric algorithms feel free to do your own research.

Symmetric encryption algorithms use only one key to encrypt and decrypt data. Their two main advantages are speed and efficiency, which makes them very advantageous for large volumes of data. One of the most well-known symmetric encryption algorithms on the market is AES, and it is precisely the one we will use in our tutorial.

To get started, we will import the encrypt package.

Then, we will add a key property to the CounterStorage class; this key will be used to encrypt and decrypt our data.

And to generate the key, we can do this using the functions from the encrypt package.

Next, we will create the encryptData function.

And finally, the decryptData function.

Now that we have functions capable of encrypting and decrypting data, the following question arises: if the keys in symmetric encryption are unique, and only the key used for the encryption process is capable of decrypting, how will we store the key in a secure way?

Utilizing Hardware-Based Security

Returning to the application we are developing, we will add a new property to the CounterStorage class.

In addition, we will add one more function: this will be responsible for retrieving from the Keychain or Keystore the key used for encryption, if it exists.

In this way, we have implemented a secure data storage solution that ensures the protection of the stored data. The complete code is as follows:

An extra layer of security with RASP

To boost the security of your applications even more, we have decided to introduce another concept in this article: RASP (Runtime Application Self-Protection). This technology helps us create security strategies based on the context in which the application is running. Through various real-time security checks, RASP can identify changes in the devices used to run the application or modifications to the application itself.

To implement RASP in Flutter applications, we recommend using freeRASP, as it offers a comprehensive range of security checks, including:

• Detection of VPN usage;

• Identification of developer mode enabled on the device;

• Checking for special permissions, such as root or jailbreak;

• Detection of execution on simulators;

• Verification of installations from unofficial app stores, ensuring the application's legitimate origin;

Additionally, when any security violation is detected, freeRASP allows you to implement countermeasures through a fallback mechanism, ensuring your application responds appropriately to potential threats. It also offers the option to receive weekly security reports via email, providing valuable insights.

In the counter app example, freeRASP could be used to delete any data stored in the application or even close the app upon identifying whether the user's device has root or jailbreak. This would help prevent unauthorized access to the data and ensure that the application runs only on secure devices.

Conclusion

Sensitive data is present in all applications, whether it's credit card information, user tokens, or other types of confidential information. It is important to emphasize that security is an ongoing process. In this article, we explored some security concepts, such as Cryptography, Access Control, Hardware-Based Security, and RASP, and how they assist us on the journey to make our application environments increasingly secure.

As developers, we must always prioritize best practices in data security and stay attentive to the latest updates of our environment and possible vulnerabilities, continuously strengthening the strategies we adopt in our applications.

We encourage you to implement the strategies discussed in this article and to continue delving into topics related to data storage insecurity. If you have comments about this article, we would be happy to receive an email from you.

The excellence in mobile security has allowed us to develop a ground-breaking enhancement for mobile API security. Let’s look at the AppiCrypt®, a powerful tool that provides proof of app and device integrity for backends. We will explain common questions about these similar technologies and the application domains they can cover.

There has been a long-standing need to protect APIs against malicious requests and reverse-engineering attempts for the past years. APIs have become an attractive target for cybercriminals trying to seize business assets through information scraping, password brute force attacks, DDoS attacks, MitM attacks, fake accounts, remote code executions, and JSON denial-of-service attacks.

The mobile-first strategy heavily depends on the protection of both the application and API sides. API keys used within your application can be easily retrieved and misused. You need to remember that the mobile application installed on the users’ mobile devices is running in an uncontrolled and untrusted environment. It doesn’t matter whether it’s a renowned device brand like Samsung Galaxy or a EMV POS terminal. There are multiple ways your app may leak secrets.

The basics: API keys, client authentication, and pinning

From the API perspective, all calls must be performed over a secure channel between the client app and the API service. You will primarily utilize HTTPS and TLS in the majority of cases. Static and preferably dynamic certificate pinning (SSL pinning) can be used to provide verification of the backend.

The only thing missing is the verification of the authenticity of the client. The most popular choice (check this awesome write-up) is sending the API key within the requests header. Such authentication is often hardcoded into the clients code. Unfortunately, simple reverse engineering is enough to steal both API keys and client authentication secrets.

Once you acknowledge it is not secure enough, you can defer MitM by using SSL pinning and strengthen your application self-protection by using Runtime Application Self-Protection (RASP) suite like a freeRASP to mitigate more attack vectors from within the App. The device is deeply inspected to determine whether it is rooted, jailbroken, or an emulator. Subsequently, the application is scanned to ensure it hasn’t been tampered with, reverse-engineered, run with debugger or repackaged. Both phases are needed to determine whether the application’s backends are communicating with a legitimate application running on an approved/genuine mobile device.

App authenticity and integrity of the device and the application can be additionally verified by remote attestation services like Play Integrity for Google Play enabled Android phones or DeviceCheck for iOS are good technologies but they have significant drawbacks that we will review later in detail. The good things are that they address API vulnerabilities that WAF and API gateway solutions cannot address as they miss endpoint integrity controls.

AppiCrypt® App and Device Attestation

An AppiCrypt® is a technique that ensures cryptographic evidence or proof of client App authenticity and integrity. On top of that, it provides device identity with security risk scoring for fraud prevention, enabling more sophisticated techniques like channel binding, device binding to users, step-up authentication, and others.

AppiCrypt® technology is the innovative solution that stands for App Integrity Cryptogram. Thanks to this technology, you can implement the idea of mobile endpoint protection in the concept of zero trust. AppiCrypt is the cryptographic integrity proof of both mobile OS and App that can help prevent mobile API abuse and eliminate the intrinsic weakness of standalone RASP protection.

Generally speaking, the RASP is always just mitigation of Reverse Engineering risk by making the attacker’s job more difficult. Conceptually, the attacker can cut off the RASP part from the app by tampering. So it depends mainly on the attackers’ experience, efforts, and resources available to break the RASP protection.

AppiCrypt solves similar problems as device attestation services like Play Integrity and DeviceCheck. In contrast to such attestation solutions, it doesn’t depend on external web services and doesn’t introduce any outage risk due to external party service unavailability. AppiCrypt solves significant security problems with minimum integration efforts on both application and backend sides.

The idea behind this technology is not just to protect API against attackers trying to impersonate legit App calls but also to let your backend know that RASP controls were overcome or turned off by attackers. So gateway can easily block the session if the App integrity is compromised, and only

in the case that RASP control passed API calls can be processed by backends. Moreover, AppiCrypt is enhanced with fine-grained application security intelligence for backends (like UI overlays, accessibility service usage, etc. ).

Play Integrity (SafetyNet) Attestation is not your savior

You’ve most probably heard about Google Play Integrity. Google’s attestation tool got quite popular because it is preinstalled on common devices equipped with Google Mobile Services. Like the AppiCrypt, it helps determine the overall integrity of the device. Make no mistake. Play Integrity, nor AppiCrypt, cannot replace proper Security Development Lifecycle (SDL), and both serve as additional security layers.

Play Integrity’s attestation information provides generalized binary conclusions about the device’s eligibility. The two checks are Basic integrity (“basicIntegrity”: true/false) and CTS profile match check based on (“ctsProfileMatch”: true/false). Yet the second one is only relevant to devices that have been Google-certified. Unfortunately, this gives no clue if you want to support specific platforms (i.e., EMV POS Terminal) or use-cases (i.e., Gaming Emulators) that Google considers inappropriate. The thing is, many users use unlocked devices because they are cheaper to get from 3rd party resellers, so you can’t rely on Play Integrity’s boolean result. Keep in mind that many devices (i.e., affordable Xiaomi models) are shipped with GMS but didn’t pass Google certification. Finally, it gives no threat signals also.

Common Play Integrity Disadvantages

• It works only if Google Play Services and good network connectivity are available.

• Downtimes may occure time-to-time (see figure below)

• It has a high response time caused by network latency and processing time

• Play Integrity Attestation fails under many conditions based on network, quota, and other transient problems.

• You need to implement verification of the Play Integrity’s result on your backend.

• It doesn’t involve many checks (i.e., tapjacking, accessibility service abuse, screen lock status)

• Google has no security process to ensure that an OEM ROM is clean. Hence, Play Integrity won’t guarantee you the safety of OEM ROM.

(original Google article)

AppiCrypt vs. Play Integrity Pros and Cons

Pros of AppiCrypt

• Universal across all platforms (Android with or without Google Services, iOS, Flutter)

• Verification serverless component ready to use (i.e., AWS lambda authorizer)

• Suited for demanding business (Fin-Tech, Healthcare, Gaming, Government)

• Fine-grained threat signals

• Reaction based on device identifiers, GPS emulation status, and screen lock status

• Attestation even in lousy network connection without quota issues and other transient problems

• Supports devices with an unlocked bootloader

• Supports devices with a custom system ROMs

• Supports devices for which the manufactured didn’t apply for, or pass, Google certification

• Supports devices with a system image built directly from the Android Open Source Program source files.

• Low latency

• Zero dependencies on Google servers middleware means no single point of failure.

Pros of Play Integrity

• Free quota allotment (per project) for calling the Play Integrity Attestation API is 10,000 requests per day and five requests per minute.

• Developed and supported by the official Android team

• Checks verified boot

AppiCrypt vs. Play Integrity Application Domains

The true strength of AppiCrypt lies in its ability to protect multiple application domains. Be it an iPhone, iPad, Amazon Fire Tablet, EMV POS Terminal, or Kiosk, you can use the same AppiCrypt and its backend component. If you need protection in every possible environment, the AppiCrypt is right for you.

To be fair, the Play Integrity also has some advantages over AppiCrypt. Play Integrity’s deep system integration allows for boot integrity checks thanks to better access to the trusted execution environment (TEE). After all, it’s developed directly by the Android team.

AppiCrypt application domains:

• Virtually every Android device

• iOS (iPhone, iPad)

• Flutter apps

• Huawei & Honor Devices since Huawei lost Google

• EMV POS Terminals

• Performance Critical Apps

• Amazon Fire Tablets

• Self-service Tablets

• Kiosks

• Gaming Emulators

• Non-Google Areas (China)

• Devices with custom ROMs

Enterprise Services

AppiCrypt is courtesy of Talsec. If you are looking for a solution tailored to your specific needs, contact us at https://talsec.app. We provide enhanced RASP protection with malware detection and detailed configurable threat reactions, immediate alerts, and penetration testing of your product to our commercial customers with a self-hosted cloud platform. To get the most advanced protection compliant with PSD2 RT and eIDAS and support from our experts, contact us via https://talsec.app/contact. written by Tomáš Soukal, Mobile Dev and Security Consultant at Talsec

https://talsec.app | info@talsec.app | Read also 5 Things John Learned Fighting Hackers of His App — A must-read for PM’s and CISO’s

Overview of "RASP techniques not implemented" weakness

RASP (Runtime Application Self-Protection) encompasses techniques such as root or jailbreak detection, unauthorised code or code execution, malware detection, system state, data logging and data flow. It provides a systematic, organised management approach to securing mobile applications in real time from potential threats.

These techniques:

• Ensure that the application flow remains secure and untampered at all times.

• Enable applications to detect and trigger responses to threats, such as:

  • Warning the user.

  • Killing the app.

  • Locking access to certain features.

Without RASP implementation, applications remain vulnerable to attacks during runtime. RASP techniques assure that the app continuously monitors both its own state and the device environment to detect threats like malware, root, or integrity issues.

Additional benefits of implementing these techniques might include:

• Independent decoupled protection updates.

• Remote configuration of security rules.

• Threat intelligence gathering.

• Fast security incident remediation.

• Providing data for security analysis.

Speed and timing of checks is also important and crucial for response times and ensuring no gaps in detection rounds, with control timing checking sensitive steps in the app. Incorporating RASP into an app ensures continuous protection from threats, ultimately minimising risk and improving overall security.

Modes of Introduction

Mobile app security and user security can be disrupted in various scenarios, including:

• The application does not comprehensively process information and fails to account for system weaknesses or its own vulnerabilities, potentially leading to breached environment integrity.

• Direct reactions to detected threads are not properly executed or integrated into the application’s business logic.

• Security rules cannot be effectively defined based on discovered weaknesses, as this approach lacks the broader perspective needed to address all potential threats and ensure comprehensive protection.

Impact

• Loss of Control and Monitoring: One of the key advantages of RASP is the ability to continuously control and monitor the mobile app’s state and the device environment in real-time. Without these features, the application may fail to detect or respond to unauthorised modifications, malware presence, or tampering attempts.

• Missed Threat Intelligence: Without continuous monitoring, security checks, and data logging, we lose a critical overview of potential threats, making it harder to identify emerging attack patterns and respond to malicious activities effectively.

• Loss of Manageability and Updateability of Detection Techniques: Without RASP, applications lose the ability to update security rulesets, reset policies/settings, and adjust risk scoring in older or already released apps.

Mitigation

• To enhance the security of your mobile application, implement detection mechanisms that continuously monitor the app's state and device environment.

• Implement response actions for detected threats to mitigate potential risks, such as:

  • Killing the app,

  • Warning the user,

  • Logging information about potential risks to the database.

How to test "RASP techniques not implemented"

RASP (Runtime Application Self-Protection) is designed to monitor and protect the application during runtime by detecting and responding to threats in real-time. The test verifies if the application can identify and react to malicious modifications, such as code tampering, root or jailbreak environment, and attempts to bypass security mechanisms. It also checks if the application has the ability to protect sensitive data and prevent unauthorised access to critical operations or features.

By conducting this test, we ensure that the app is capable of defending against runtime attacks and maintaining its integrity even in compromised environments. If RASP techniques are not implemented or are improperly configured, the app may be vulnerable to various security threats, including data breaches, unauthorised access, and malicious modifications.

Steps

1. Ensure that all security checks and protection mechanisms expected from RASP are present and enabled with the application. To test the RASP policy that the app enforces, a written copy of the policy must be provided. The policy should define available checks and their enforcement. For example:

   • Root detection.

   • Screen lock enforcement.

   • Code integrity checks.

   • Detection of dynamic analysis.

2. Based on the previous step, attempt to simulate threats to test if the application reacts as expected. This can involve various scenarios such as:

   • Launching the mobile application on a rooted device.

   • Launching the mobile application on a device without a screen lock enabled.

   • Attempting to repackage the application and launching it.

   • Launching the application in an emulator.

3. Verify that the application properly detects and responds to potential threats. There are various scenarios in which a mobile application can respond to these threats, such as:

   • Killing the app.

   • Warning the user about the detected threat.

   • Logging information about potential risks to a database or SIEM.

Observation

The output depends on the specific reactions set up for the mobile application. The results should demonstrate the app’s behaviour when a threat is detected or triggered, for example:

• Application is terminated.

• Application displays a warning message.

• Application sends information to a database or SIEM. Testers should ensure that the collected threat intelligence data are rich enough.

Evaluation

The test case fails if the mobile application does not react as expected to the detected threats.

written by Martin Žigrai, Tomáš Soukal

At Talsec, we believe apps should have the option to detect risky environments, including suspicious malware, to ensure no sensitive information is leaked. Let us introduce our advanced in-app malware protection!

https://docs.talsec.app/freemalwaredetection

Active protection against:

• Known malware

• Ongoing malware campaigns

• Counterfeit app clones

• Tapjacking

• Accessibility Screen readers

• Other potentially risky apps

Malware detection capabilities include:

• Scanning the device for blocklisted apps

• Identifying apps installed from untrusted app stores

• Detecting side-loaded apps from unverified sources

• Apps requiring risky permissions

Reporting and logging:

• Any unwanted findings are reported back to the app

• All findings are logged for further analysis and tracking

https://docs.talsec.app/freemalwaredetection

Written by Tomáš Soukal — Security Consultant

System VPNs may be used to mask illicit activities, evade compliance controls, or access services from unauthorized regions.

Detecting a running VPN service on mobile devices is critical for security-sensitive applications, as it can indicate potential privacy and security risks. VPNs can obscure the user’s actual IP address and route data through servers potentially under external control, which might interfere with geographical restrictions and bypass network security settings intended to protect data integrity and confidentiality.

Such anonymizing features could be exploited to mask illicit activities, evade compliance controls, or access services from unauthorized regions. FreeRASP checks whether the system VPN is enabled.

Enjoy the ultimate threat modeling knowledge sharing refined through insights from hundreds of sessions with mobile security experts and shared with many CTOs, CISOs, and senior mobile developers who develop for Android, iOS, React Native, and Flutter.

It's ideal for team training workshops as a practical guide to better securing mobile apps and backend APIs, offering actionable insights.

• Threat Modeling

• TOFU (Trust On First Use)

• App and Device Enrollment

• Detection, Monitoring, and Security

It focuses on the most exploitable threat vectors, including

• Session Hijacking,

• Token Hijacking,

• Rooting and Jailbreaking (Magisk),

• App Impersonation,

• App Tampering,

• App Cloning,

• App Repackaging,

• Dynamic Hooking (Frida),

• Reverse Engineering and respective prevention and remediation approaches like a RASP.

presented by Tomas Soukal.

While there are multiple options when it comes to choosing a library that implements secure storage in React Native, it is crucial to ensure that the data are stored properly and ideally without any known vulnerabilities. At Talsec, we made an effort to go through the most popular packages, so you can get an image of what is on offer.

This article assumes you are familiar with:

• How data storage works on native platforms

• Android Keystore, Keychain and how they are used

How to approach secure storage challenges?

Recently, the Talsec team started to support React Native by providing the freeRASP and RASP+ SDKs. We are currently exploring ways how we could go even further and are considering to add a secure storage solution that would follow the latest security standards. In order to proceed, we evaluated the existing secure storage options within React Native and seek input from the community to understand your expectations regarding this feature.

We would love to share our findings so far with a brief description of various secure storage packages available for React Native, along with their benefits and potential vulnerabilities:

1. react-native-keychain

• ✅ Pros: This is a popular package that securely stores sensitive information using the Keychain on iOS and the Keystore on Android. It encrypts data and provides secure storage for confidential data.

• ⛔️ Cons: While react-native-keychain provides secure storage, it is not immune to all vulnerabilities. The package stores sensitive information, e.g. username and password in clear text in the keychain file, and you can find several concerning issues that are open on GitHub, mentioning that the data from iOS keychain can be retrieved. On top of that, it can only store username/password combination.

2. react-native-encrypted-storage

• ✅ Pros: react-native-encrypted-storage is another third-party library that offers secure storage for sensitive data. It uses EncryptedSharedPreferences on Android and Keychain on iOS, encrypts data using AES-256 encryption, providing an extra layer of security.

• ⛔️ Cons: There are some memory leaks detected by Xcode profiler and Keychain is not cleared when your app is uninstalled on iOS — this issue, however, is well documented and can be fixed.

3. rn-secure-storage

• ✅ Pros: rn-secure-storage encrypts data using AES-256 encryption and securely stores it on the device. Plus, it can store any [key, value] pair.

• ⛔️ Cons: The implementation uses secure-preferences package to store the data, which is nowadays deprecated and it is encouraged to use EncryptedSharedPreferences from androidx.security instead.

4. react-native-async-storage

Okay, this package doesn’t implement any kind of secure storage and is not intended to store any sensitive data. However, it is still a popular solution for data storage in React Native, prompting us to mention it in this article as well.

• ✅ Pros: Offers a simple asynchronous storage. It is built on top of the original React Native’s AsyncStorage and provides a convenient API for storing and retrieving data.

• ⛔️ Cons: The package requires devs to handle encryption of the data on their own, as it stores data in plain text, making it vulnerable to unauthorized access if the device is compromised. We would suggest to avoid using AsyncStorage for sensitive information like passwords or authentication tokens.

Problems with Hardware-Backed Keystores

Although many devices offer hardware-backed keystores, there is a significant number that lacks it. Moreover, certain devices, particularly those running on Android, face challenges with hardware-backed keystores due to manufacturer-provided software. These implementations either fail to function properly or resort to software-backed alternatives. I suggest checking out the list of public resources related to Trusted Execution Environment (TEE). This resource compilation provides valuable information on reverse-engineering techniques and strategies for achieving trusted code execution on ARM devices.

Another important consideration is that although hardware-backed keystores may provide better protection against key extraction, they are still susceptible to runtime attacks, just like software-backed keystores. During runtime, attackers can still access encrypted data stored in the keystore using rooted devices, a repackaged or tampered app, or hooking frameworks.

Therefore, we have concluded that the most effective approach which will mitigate the risk of runtime attacks is a combination of secure storage with RASP-based solution.

Boosting Software-Backed Keystore with RASP

By integrating a software-backed keystore into the RASP (Runtime Application Self-Protection) solutions, we can address two critical aspects simultaneously:

1. Reliability: The enhanced RASP solution will offer a dependable keystore mechanism that does not rely on secure hardware. This ensures the integrity and protection of cryptographic keys, even on devices that lack hardware-backed security features.

2. Security: While the keystore itself remains vulnerable to threats like root access and runtime hooks, a closely integrated keystore within RASP can mitigate these risks. It can dynamically determine whether to store or retrieve data based on the current security state of the device.

Through the integration of a software-backed keystore, the enhanced RASP solution provides a comprehensive and reliable approach to data protection, overcoming limitations related to hardware availability and compromised devices.

That’s it!

We hope this summary helps you make an informed decision when considering a secure storage option for your React Native project. But also, we’d be happy to hear your opinion. Would you use a software-based secure storage SDK for React Native that utilizes a hardcoded obscured encryption key?

Please share your experiences, suggestions, and any other secure storage tips. Let’s discuss in the comments below! 👇

Happy coding.

written by Tomas Psota, developer at Talsec

https://talsec.app | info@talsec.app

Authentication vulnerabilities remain one of the most critical security concerns in mobile application development. When building Flutter applications, developers often overlook crucial security aspects while integrating third-party authentication providers.

The combined total of apps in the Apple App Store and Google Play Store has surpassed 6 million, but a startling 75% of these apps have at least one security flaw, highlighting the widespread vulnerability in mobile app ecosystems.

The Stakes: Beyond Basic Authentication

Mobile authentication attacks have evolved beyond simple credential theft. Modern attack vectors target the entire authentication flow, from initial user input to session management. A compromised authentication system doesn't just expose user credentials - it potentially compromises your entire API surface area.

Consider this scenario: An attacker extracts an improperly stored refresh token from a jailbroken device. Even with perfect password security and MFA implementation, this single vulnerability allows indefinite API access through token refresh mechanisms.

While providers like Firebase, Supabase, and Auth0 implement encryption to safeguard user data. providers manage backend security, developers must ensure secure practices in their apps to eliminate vulnerabilities. The post will provide actionable insights on encryption, secure token storage, and robust communication strategies for Flutter apps.

Understanding user flow from login / logout

The authentication flow in a Flutter application represents a complex sequence of security-critical operations. Each step presents unique vulnerabilities that malicious actors can exploit. Let's analyse the complete flow, focusing on security implications at each stage.

Security Checkpoints

1. Launch the App: The app initializes and prepares the login screen. At this stage, failing to sanitize inputs or enforce app integrity checks could expose the app to tampering.

2. Input Validation: Users enter their credentials. Weak validation can allow injection attacks or malformed inputs.

3. Initiate Login Request: The app sends credentials to the server. Without secure communication channels, credentials may be intercepted.

4. Receive Authentication Response: A successful response contains tokens; insecure handling can lead to theft or misuse.

5. Token Management: Tokens need secure storage and monitoring for expiration. Improper storage can lead to credential exposure.

6. API Calls and Logout: Valid tokens allow API access, while the logout process ensures no lingering session data exists.

Implementing a secure auth flow

JWT (JSON Web Tokens) is a compact, URL-safe way to securely transmit information between two parties as a JSON object. It’s commonly used for authentication and information exchange. A JWT is composed of three parts:

1. Header: Specifies the token type (JWT) and the signing algorithm (e.g., HS256).

2. Payload: Contains the claims (data like user info or permissions). Claims can be public, private, or registered (e.g., iss, exp).

3. Signature: Ensures the token’s integrity using the header, payload, and a secret or public/private key.

JWTs are signed, not encrypted, making them verifiable but not inherently confidential. They’re ideal for stateless authentication and are often used in APIs, enabling secure communication without server-side storage.

JSON Web Tokens form the backbone of modern authentication systems. Their structure requires careful handling and validation:

Before we dive into the implementation, let's set up our project with the necessary dependencies. Add these to your pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter
  supabase_flutter: ^1.10.25  # For authentication
  flutter_secure_storage: ^9.0.0  # For secure token storage
  provider: ^6.1.1  # For state management
  freerasp: ^6.0.0  # For security checks

1. Setting Up Security Service

The Security Service acts as your application's first line of defense. It continuously monitors the device environment and enforces security policies. This service helps protect your app against:

• Device Tampering: Detects rooted (Android) or jailbroken (iOS) devices

• Development Tools: Identifies debugging attempts and emulator usage

• Runtime Threats: Monitors for malicious hooks and code modifications

• Brute Force Attacks: Implements rate limiting to prevent repeated login attempts

The service uses freeRASP for device integrity checks and maintains an in-memory store of failed login attempts. When security violations are detected, it notifies the UI layer to take appropriate action.

The security service monitors device integrity and manages rate limiting. Create lib/services/security_service.dart:

import 'package:flutter/foundation.dart';
import 'package:freerasp/freerasp.dart';

class SecurityService extends ChangeNotifier {
  bool _isJailbroken = false;
  bool _isEmulator = false;
  bool _isDebuggerAttached = false;
  bool _isHooked = false;
  bool _isAppTampered = false;
  
  final Map<String, int> _failedAttempts = {};
  final int _maxAttempts = 5;
  
  late TalsecConfig _config;
  late ThreatCallback _callback;

  SecurityService() {
    _initConfig();
    _initCallback();
    _initSecurity();
  }

  bool get isDeviceSecure => !_isJailbroken && 
                           !_isEmulator && 
                           !_isDebuggerAttached && 
                           !_isHooked && 
                           !_isAppTampered;

  void _initConfig() {
    _config = TalsecConfig(
      androidConfig: AndroidConfig(
        packageName: 'your.package.name',
        signingCertHashes: ['your_cert_hash'],
        supportedStores: ['com.android.vending'],
      ),
      iosConfig: IOSConfig(
        bundleIds: ['your.bundle.id'],
        teamId: 'YOUR_TEAM_ID',
      ),
      watcherMail: 'security@yourapp.com',
      isProd: !kDebugMode,
    );
  }

  // Rate limiting methods
  bool checkRateLimit(String identifier) {
    return _failedAttempts[identifier] ?? 0 < _maxAttempts;
  }

  void incrementFailedAttempt(String identifier) {
    _failedAttempts[identifier] = (_failedAttempts[identifier] ?? 0) + 1;
  }

  void resetFailedAttempts(String identifier) {
    _failedAttempts.remove(identifier);
  }
}

2. Implementing Token Management

• Why Secure Token Storage Matters

  Authentication tokens are like digital keys to your application. Without proper lifecycle management, these keys could become a security liability. Let's understand why token management is crucial and how we've implemented it.

  • Understanding the Risks

    If an attacker obtains a token stored in plain text or one that never expires, they could potentially access a user's account indefinitely. Additionally, without proper refresh mechanisms, users might experience frequent, frustrating logouts.

  Here's how tokens are often stored insecurely using SharedPreferences:

class InsecureTokenStorage {
  static const _tokenKey = 'auth_token';
  
  Future<void> storeToken(String token) async {
    final prefs = await SharedPreferences.getInstance();
    await prefs.setString(_tokenKey, token);
  }

  Future<String?> getToken() async {
    final prefs = await SharedPreferences.getInstance();
    return prefs.getString(_tokenKey);
  }
}

Security Vulnerabilities

1. Easy Extraction:

   • On rooted/jailbroken devices, attackers can directly read SharedPreferences files

   • Tokens are stored in plain text at /data/data/your.package.name/shared_prefs/your_prefs.xml

2. Example Attack Scenario:

# On a rooted Android device
adb shell
su
cd /data/data/your.package.name/shared_prefs
cat your_prefs.xml
# Output might look like:
# <?xml version='1.0' encoding='utf-8' standalone='yes' ?>
# <map>
#   <string name="auth_token">eyJhbGciOiJIUzI1NiIs...</string>
# </map>

Implementing Secure Token Storage

Now that we understand the risks, let's implement a secure solution using flutter_secure_storage

The Token Service handles the secure storage and lifecycle management of authentication tokens. It's designed to:

• Secure Storage: Use platform-specific encryption (EncryptedSharedPreferences for Android, Keychain for iOS)

• Auto-Refresh: Proactively refresh tokens before expiration to maintain session continuity

• Clean Lifecycle: Properly handle token storage, updates, and deletion

• Error Recovery: Implement fallback mechanisms for token refresh failures

This service ensures that sensitive authentication data is never exposed in plain text and maintains secure session state across app launches.

Create lib/services/token_service.dart for secure token storage:

import 'package:flutter_secure_storage/flutter_secure_storage.dart';
import 'dart:async';

class TokenService {
  final _storage = const FlutterSecureStorage();
  Timer? _refreshTimer;
  Function(String)? onTokenRefreshNeeded;

  Future<void> storeTokens(Map<String, String> tokens) async {
    await _storage.write(
      key: 'access_token',
      value: tokens['access_token'],
      aOptions: _getAndroidOptions(),
      iOptions: _getIOSOptions(),
    );
    
    await _storage.write(
      key: 'refresh_token',
      value: tokens['refresh_token'],
      aOptions: _getAndroidOptions(),
      iOptions: _getIOSOptions(),
    );

    _scheduleTokenRefresh();
  }

  AndroidOptions _getAndroidOptions() => const AndroidOptions(
    encryptedSharedPreferences: true,
  );

  IOSOptions _getIOSOptions() => const IOSOptions(
    accessibility: KeychainAccessibility.first_unlock,
  );

  void _scheduleTokenRefresh() {
    _refreshTimer?.cancel();
    _refreshTimer = Timer(const Duration(minutes: 55), () {
      if (onTokenRefreshNeeded != null) {
        getRefreshToken().then((token) {
          if (token != null) onTokenRefreshNeeded!(token);
        });
      }
    });
  }
}

3. Supabase Authentication Service

This service integrates Supabase authentication with our security layers. It implements:

• PKCE Flow: Uses Proof Key for Code Exchange for enhanced security

• Session Management: Maintains and validates authentication state

• Token Handling: Coordinates with TokenService for secure storage

• Error Management: Provides structured error handling for auth operations

• State Recovery: Implements session recovery after app restarts

The service acts as a bridge between Supabase's authentication system and our custom security implementations.

Create lib/services/supabase_auth_service.dart:

import 'package:flutter/foundation.dart';
import 'package:supabase_flutter/supabase_flutter.dart';
import 'token_service.dart';

class SupabaseAuthService extends ChangeNotifier {
  late final SupabaseClient _supabaseClient;
  final TokenService _tokenService = TokenService();
  bool _initialized = false;

  Future<void> initialize() async {
    await Supabase.initialize(
      url: 'YOUR_SUPABASE_URL',
      anonKey: 'YOUR_ANON_KEY',
      authOptions: const FlutterAuthClientOptions(
        authFlowType: AuthFlowType.pkce,
        autoRefreshToken: true,
      ),
    );
    
    _supabaseClient = Supabase.instance.client;
    _initialized = true;

    // Listen to auth state changes
    _supabaseClient.auth.onAuthStateChange.listen(_handleAuthStateChange);
    
    await _recoverSession();
    notifyListeners();
  }

  Future<AuthResponse> login({
    required String email,
    required String password,
  }) async {
    try {
      final response = await _supabaseClient.auth.signInWithPassword(
        email: email,
        password: password,
      );
      notifyListeners();
      return response;
    } catch (e) {
      throw _handleAuthException(e);
    }
  }
}

4. User Interface Implementation

Create lib/screens/login_screen.dart:

class LoginScreen extends StatefulWidget {
  @override
  _LoginScreenState createState() => _LoginScreenState();
}

class _LoginScreenState extends State<LoginScreen> {
  final _formKey = GlobalKey<FormState>();
  final _emailController = TextEditingController();
  final _passwordController = TextEditingController();
  bool _isLoading = false;

  Future<void> _handleLogin() async {
    final securityService = Provider.of<SecurityService>(context, listen: false);
    final email = _emailController.text.trim();

    // Security checks
    if (!securityService.isDeviceSecure) {
      _showSecurityWarning();
      return;
    }

    // Rate limiting
    if (!securityService.checkRateLimit(email)) {
      _showRateLimitWarning();
      return;
    }

    if (_formKey.currentState!.validate()) {
      setState(() => _isLoading = true);
      try {
        final success = await context.read<AuthService>().login(
          email,
          _passwordController.text,
        );

        if (!success && mounted) {
          securityService.incrementFailedAttempt(email);
          ScaffoldMessenger.of(context).showSnackBar(
            const SnackBar(content: Text('Login failed')),
          );
        } else {
          securityService.resetFailedAttempts(email);
        }
      } finally {
        if (mounted) setState(() => _isLoading = false);
      }
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Secure Login')),
      body: Consumer<SecurityService>(
        builder: (context, security, _) => Column(
          children: [
            if (!security.isDeviceSecure)
              SecurityWarningBanner(),
            LoginForm(
              formKey: _formKey,
              emailController: _emailController,
              passwordController: _passwordController,
              isLoading: _isLoading,
              onLogin: _handleLogin,
            ),
          ],
        ),
      ),
    );
  }
}

5. App Initialization and Integration

The initialization phase is crucial as it sets up the security foundation for your entire application. This phase orchestrates the proper setup and interaction of all security components.

Update your lib/main.dart:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  
  final supabaseAuth = SupabaseAuthService();
  await supabaseAuth.initialize();
  
  final authService = AuthService(supabaseAuth: supabaseAuth);
  final securityService = SecurityService();
  
  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider<SupabaseAuthService>(
          create: (_) => supabaseAuth,
        ),
        ChangeNotifierProvider<AuthService>(
          create: (_) => authService..init(),
        ),
        ChangeNotifierProvider<SecurityService>(
          create: (_) => securityService,
        ),
      ],
      child: const MyApp(),
    ),
  );
}

6. Securing Network Communications

While our project uses Supabase's built-in networking, lot of Flutter applications use Dio for HTTP communications. Let's explore how to implement secure networking with Dio.

Imagine sending a postcard versus a sealed letter. HTTP is like a postcard - anyone handling it can read its contents.

Implementing Secure Network Layer

class SecureApiService {
  late Dio _dio;
  final TokenService _tokenService;

  SecureApiService(this._tokenService) {
    _dio = Dio(BaseOptions(
      baseUrl: 'https://api.yourserver.com',
      validateStatus: (status) => status! < 500,
      connectTimeout: const Duration(seconds: 5),
      receiveTimeout: const Duration(seconds: 3),
    ));
    
    _configureSecurityFeatures();
  }

  void _configureSecurityFeatures() {
    // 1. HTTPS Enforcement & Certificate Pinning
    (_dio.httpClientAdapter as DefaultHttpClientAdapter)
        .onHttpClientCreate = (client) {
      SecurityContext context = SecurityContext(withTrustedRoots: true);
      context.setTrustedCertificatesBytes(yourCertBytes);
      
      // Force HTTPS only
      client.badCertificateCallback = 
          (X509Certificate cert, String host, int port) => false;
      
      return client;
    };

    // 2. Request/Response Security
    _dio.interceptors.add(InterceptorsWrapper(
      onRequest: (options, handler) async {
        // Add security headers
        options.headers['X-Security-Header'] = 'value';
        options.headers['X-Request-ID'] = _generateRequestId();
        
        // Encrypt sensitive data if needed
        if (options.data is Map && options.data['sensitive'] != null) {
          options.data['sensitive'] = await _encryptData(options.data['sensitive']);
        }
        
        return handler.next(options);
      },
      onResponse: (response, handler) async {
        // Validate response integrity
        if (!_validateResponseIntegrity(response)) {
          return handler.reject(
            DioError(
              requestOptions: response.requestOptions,
              error: 'Response integrity check failed',
            ),
          );
        }
        return handler.next(response);
      },
    ));

    // 3. Token Management
    _dio.interceptors.add(InterceptorsWrapper(
      onRequest: (options, handler) async {
        final token = await _tokenService.getAccessToken();
        if (token != null) {
          options.headers['Authorization'] = 'Bearer $token';
        }
        return handler.next(options);
      },
      onError: (error, handler) async {
        if (error.response?.statusCode == 401) {
          if (await _refreshToken()) {
            return handler.resolve(await _retryRequest(error.requestOptions));
          }
        }
        return handler.next(error);
      },
    ));
  }

  // Helper methods for security features
  String _generateRequestId() => DateTime.now().millisecondsSinceEpoch.toString();
  
  Future<String> _encryptData(String data) async {
    // Implement your encryption logic
    return data;
  }
  
  bool _validateResponseIntegrity(Response response) {
    // Implement response validation logic
    return true;
  }

  Future<bool> _refreshToken() async {
    try {
      // Implement token refresh logic
      return true;
    } catch (e) {
      return false;
    }
  }

  Future<Response<dynamic>> _retryRequest(RequestOptions requestOptions) async {
    final token = await _tokenService.getAccessToken();
    requestOptions.headers['Authorization'] = 'Bearer $token';
    return _dio.fetch(requestOptions);
  }

  // Handle security errors
  void _handleSecurityError(DioError error) {
    if (error.type == DioErrorType.badCertificate) {
      _logSecurityEvent('Invalid Certificate');
    }
    // Handle other security errors
  }

  void _logSecurityEvent(String event) {
    // Implement security logging
  }
}

7. Unit Testing

• Authentication testing is crucial for ensuring your security measures work as intended. Our testing approach combines mock generation with comprehensive test scenarios to verify authentication flows, error handling, and security constraints.

• Setting Up Authentication Tests

  To implement our tests, we need two key files:

  1. auth_test.dart: Contains our test scenarios and implementations

  2. auth_test.mocks.dart: Auto-generated mocks for simulating authentication services

First, ensure you have the required dependencies in your pubspec.yaml:

dev_dependencies:
  flutter_test:
    sdk: flutter
  mockito: ^5.4.4
  build_runner: ^2.4.8

• Complete Test Implementation

  In our testing setup, we leverage Mockito's powerful code generation capabilities to create mock services. By adding the @GenerateMocks([SupabaseAuthService]) annotation to our test file, we tell Mockito which classes need to be mocked. When we run flutter pub run build_runner build, Mockito automatically generates auth_test.mocks.dart, which contains a sophisticated mock implementation of our SupabaseAuthService.

// auth_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:login_app/services/auth_service.dart';
import 'package:login_app/services/supabase_auth_service.dart';
import 'package:mockito/mockito.dart';
import 'package:mockito/annotations.dart';
import 'package:supabase_flutter/supabase_flutter.dart';

import 'auth_test.mocks.dart';

@GenerateMocks([SupabaseAuthService])
void main() {
  group('Authentication Tests', () {
    late MockSupabaseAuthService mockSupabaseAuth;
    late AuthService authService;

    setUp(() {
      mockSupabaseAuth = MockSupabaseAuthService();
      authService = AuthService(supabaseAuth: mockSupabaseAuth);
      
      // Setup default mock behavior
      when(mockSupabaseAuth.isAuthenticated).thenReturn(false);
      when(mockSupabaseAuth.currentUser).thenReturn(null);
    });

    test('Initialize auth service', () async {
      // Arrange
      when(mockSupabaseAuth.initialize()).thenAnswer((_) async => {});

      // Act
      await authService.init();

      // Assert
      verify(mockSupabaseAuth.initialize()).called(1);
    });

    test('Sign in with valid credentials succeeds', () async {
      // Arrange
      final mockUser = User(
        id: 'mock_user_id',
        email: 'test@example.com',
        aud: 'authenticated',
        role: 'authenticated',
        createdAt: DateTime.now().toIso8601String(),
        appMetadata: {},
        userMetadata: {},
        phone: '',
      );

      final mockResponse = AuthResponse(
        session: Session(
          accessToken: 'mock_access_token',
          refreshToken: 'mock_refresh_token',
          tokenType: '',
          expiresIn: 3600,
          user: mockUser,
        ),
        user: mockUser,
      );

      when(mockSupabaseAuth.login(
        email: 'test@example.com',
        password: 'password123',
      )).thenAnswer((_) async => mockResponse);

      // Act
      final result = await authService.login('test@example.com', 'password123');

      // Assert
      expect(result, true);
      verify(mockSupabaseAuth.login(
        email: 'test@example.com',
        password: 'password123',
      )).called(1);
    });

    test('Sign in with invalid credentials fails', () async {
      // Arrange
      when(mockSupabaseAuth.login(
        email: 'wrong@example.com',
        password: 'wrongpass',
      )).thenThrow(Exception('Invalid credentials'));

      // Act
      final result = await authService.login('wrong@example.com', 'wrongpass');

      // Assert
      expect(result, false);
    });

    test('Sign up with valid data succeeds', () async {
      // Arrange
      final mockUser = User(
        id: 'new_user_id',
        email: 'new@example.com',
        aud: 'authenticated',
        role: 'authenticated',
        createdAt: DateTime.now().toIso8601String(),
        appMetadata: {},
        userMetadata: {},
        phone: '',
      );

      final mockResponse = AuthResponse(
        session: Session(
          accessToken: 'mock_access_token',
          refreshToken: 'mock_refresh_token',
          tokenType: '',
          expiresIn: 3600,
          user: mockUser,
        ),
        user: mockUser,
      );

      when(mockSupabaseAuth.signUp(
        email: 'new@example.com',
        password: 'newpass123',
      )).thenAnswer((_) async => mockResponse);

      // Act
      final result = await authService.signUp('new@example.com', 'newpass123');

      // Assert
      expect(result, true);
      verify(mockSupabaseAuth.signUp(
        email: 'new@example.com',
        password: 'newpass123',
      )).called(1);
    });

    test('Sign out succeeds', () async {
      // Arrange
      when(mockSupabaseAuth.logout())
          .thenAnswer((_) async => {});

      // Act
      await authService.logout();

      // Assert
      verify(mockSupabaseAuth.logout()).called(1);
    });

    test('Check authentication state', () {
      // Initial state
      expect(authService.isAuthenticated, false);

      // Simulate successful login
      when(mockSupabaseAuth.isAuthenticated).thenReturn(true);
      when(mockSupabaseAuth.currentUser).thenReturn(
        User(
          id: 'user_id',
          email: 'test@example.com',
          aud: 'authenticated',
          role: 'authenticated',
          createdAt: DateTime.now().toIso8601String(),
          appMetadata: {},
          userMetadata: {},
          phone: '',
        ),
      );
      
      // Verify authenticated state
      expect(authService.isAuthenticated, true);
    });

    test('Password reset request succeeds', () async {
      // Arrange
      when(mockSupabaseAuth.resetPassword('test@example.com'))
          .thenAnswer((_) async => {});

      // Act & Assert
      await expectLater(
        authService.resetPassword('test@example.com'),
        completes,
      );
      verify(mockSupabaseAuth.resetPassword('test@example.com')).called(1);
    });

    test('Password reset request fails', () async {
      // Arrange
      when(mockSupabaseAuth.resetPassword('test@example.com'))
          .thenThrow(Exception('Failed to reset password'));

      // Act & Assert
      expect(
        () => authService.resetPassword('test@example.com'),
        throwsException,
      );
    });
  });
}

Running the Tests

flutter test test/auth_test.dart

The combination of mock generation and comprehensive test scenarios provides confidence in our authentication system's reliability and security.

8. Implementing Multi-Factor Authentication (MFA)

Multi-Factor Authentication strengthens your application's security by requiring multiple forms of verification. Think of it as adding multiple locks to your front door – each additional layer makes unauthorized access significantly more difficult.

MFA relies on a combination of:

• Knowledge factors (something you know) • Passwords • PIN codes • Security questions

• Possession factors (something you have) • Mobile devices • Security tokens • Authentication apps

• Inherence factors (something you are) • Fingerprints • Face recognition • Voice patterns

• Popular MFA Methods

  • Time-based One-Time Passwords (TOTP)

    TOTP enhances security through authenticator apps that generate temporary codes using time-synchronized algorithms. These codes automatically expire after 30 seconds, providing a secure yet convenient authentication method. The time-sensitive nature ensures that intercepted codes quickly become useless, making it an effective choice for applications requiring strong security.

• SMS and Email Verification

  • SMS and email verification offer familiar authentication experiences using existing communication channels. While simple to implement and widely accessible, these methods are considered less secure due to potential vulnerabilities like SIM swapping or email compromise. They remain popular for applications where user convenience takes priority over maximum security measures.

Conclusion

Building secure authentication in Flutter requires a careful balance between security and user experience. Throughout this guide, we've explored implementing a authentication system that protects user data without compromising usability.

While our implementation provides a solid foundation for secure authentication, remember that security is not a one-time implementation. Regular reviews and updates of your security measures are essential to maintain strong protection for your users.

The principles and patterns we've discussed serve as a starting point. Your specific application may require additional security measures depending on your use case, user base, and sensitivity of data.

Keep building secure applications, stay informed about emerging security threats, and always prioritise your users' data protection.

written by Himesh Panchal

⚡Key takeaways:

• Promo abuse is a type of fraud where bad actors take advantage of a business’s sign-up bonuses, referrals, coupons, or promotions.

• MediaDRM should be preferred over device fingerprinting whenever possible.

• Ultimately, our research suggests the best device ID suitable for blocklisting is a combination of MediaDRM+device model.

• Always include multiple security layers like the AppiCrypt (protecting your mobile app’s backend API), RASP (app shielding), and KYC solutions (customer identity verification).

• Keep in mind that your specific scenario may require a different approach. Drop a message at info@talsec.app, and Talsec security experts will help you.

How to identify abuser?

Recently, we’ve faced a challenge in mobile device identification — how to identify and blocklist a fraudulent device without compromising user privacy. This issue holds particular significance for mobile application owners who frequently contend with users evading payments or exploiting various bonuses.

While it’s common to attract users with enticing bonuses during their initial sign-up, it’s crucial to recognize that this strategy comes with inherent risks and is prone to abuse. These malicious users go to the extent of reinstalling the app multiple times, attempting to gain sign-up bonuses repeatedly — a behavior we term “multi-instancing.”

Since Android alters some device IDs for each new app instance, pinpointing the same bad actor’s device becomes challenging for blocklisting. This underscores the complexity of our pursuit for an effective solution.

Good ID is unique, collision-resistant, persistent, and privacy-friendly. And Unspoofable.

In the past, you could identify a device by its MAC address or IMEI without requesting special permissions. Today, after many Android privacy-oriented changes, several semi-persistent IDs are available on Android devices, such as AndroidID, MediaDRM, GSF ID, FID, and InstanceID. Of course, asking users for any permissions with elevated access and potential security implications is unrealistic.

Each of the IDs has its ups and downs, making them useful in different scenarios; see the example table below. You can find additional information about the IDs in the Android documentation.

Alternatively, the ID can be constructed by various device fingerprint libraries (e.g., fingerprintjs-android) based on multiple device IDs, device states, OS fingerprints, or installed apps.

Let’s look closer at these IDs.

AndroidID, GSF ID, FID, InstanceID, Google Advertising ID

While these identification methods may serve well in other contexts, in our scenario, they lack the resilience needed to withstand fraudulent multi-instancing. These IDs are relatively easy to change, so only a quick explanation about downsides of each respective one:

• AndroidID changes in case of repackaging or if installed under another user on device

• GSF ID (Google Play Service Framework ID) is restricted to Google devices only and can be relatively easily spoofed by XPrivacyLua. It also changes for different users.

• FID (Firebase installation ID) won’t survive reinstallation

• InstanceID (GUID, UUID.randomUUID().toString()) is custom generated and internally stored ID, but it won’t survive reinstallation

• Google Advertising ID is not suitable at all

In summary, none of those IDs is solid enough to identify bad actors in our scenario.

Fingerprint IDs based on the fingerprintjs-android library

Notice: In the whole analysis, we worked with the fingerprintjs-android library that uses a comprehensive list of signals for stateless offline fingerprinting. The results of other fingerprinting libraries may be different. They may include more signals and heuristics based on their data insights, geolocation, IP location, TEE, and possibly other magic. Talsec collects fingerprintjs-android V3 & StabilityLevel.OPTIMAL. Differences between stability levels (STABLE — OPTIMAL — UNIQUE) can be found here.

Glance over the table above once again. At first sight, the Hardware Fingerprint (see the table above) could be the best option — it survives anything except for the Instant App event. However, there is one serious drawback to this ID — the collisions. Collisions are caused by the way the ID is calculated — as the name suggests, the ID is solely based on the device’s hardware. Imagine all the Samsung Galaxy Z Flips coming straight out of the assembly line. All of them will have the same ID in case of hardware-based fingerprint. This type of fingerprint is called a STABLE fingerprint.

On the other end, there is a UNIQUE fingerprint, which uses a considerable amount of signals to calculate the device’s ID. IDs created in this way have a high probability of matching only to one user (minimal number of collisions), but because of the high amount of signals, the ID changes quite often (e.g., with some change in settings), making one user have many IDs (making it useless in our use case). Example: ID may change if there is a change in installed apps or Data Roaming is enabled/disabled.

A third type of fingerprint is a compromise between the STABLE and UNIQUE fingerprints — an OPTIMAL fingerprint. It is less stable but more unique than the STABLE one and is collected by the Talsec SDK. But even this type of fingerprint is not as optimal as it sounds — as shown later in this article. Example: ID may change if the user switches between 12 and 24-hour clock representation or Development Settings or ADB is enabled/disabled.

Fingerprint example: `f37fc958dc6d566a8f4bf1e0fd25b510`

MediaDRM

MediaDrm is an Android API enabling the secure provision of encryption keys to MediaCodec for premium content playback. It uses DRM providers like Google’s Widevine and Microsoft’s PlayReady. During initial DRM use, device provisioning obtains a unique certificate stored in the device’s DRM service.

Not only is the MediaDRM provided by this API the same for all users on the device, but in our scenario, it’s harder to spoof and can survive many attacks. No permissions are required to get this ID.

Yet, it still has limitations. It may be missing on devices that don’t support MediaDrm. Also, MediaDRM seems to have quite a few collisions with devices of the same manufacturer, as we show further.

MediaDRM example: `e3af1aa4dacb6b6637846488b511e7643c6ac20b65c95baad164b122ecb036b6`

MediaDRM vs Fingerprint ID?

We tested five devices and emulators under multiple multi-instancing scenarios and checked whether the IDs changed or remained the same. The most interesting ones are MediaDRM and Fingerprint (V3 & V5 Optimal), so we especially paid attention to these.

Multi-instancing scenarios:

• First install of the app

• Reinstall of app

• Install in Work Profile

• Make a clone of the app using Island App

• Make a clone of the app using Parallel Space

• Make a clone of the app using Parallel Apps

• Make a clone of the app using Second Space (Xiaomi)

• Installation in Guest Profile

• Factory reset

• Android emulator vs. actual device

This tedious work was made easier thanks to a great Fingerprint OSS Demo tool.

Here are the most important observations. Not all tests could always be performed, so we did all the low-hanging fruit ones — essentially, those attackers would attempt also.

Remained the same (= good):

• MediaDRM remained the same for the First install, and Island App on the OnePlus 8 Pro

• MediaDRM remained the same for the First install and Second Space on Redmi Note 10 Pro

• MediaDRM remained the same after the Factory reset on the OnePlus 8 Pro

• MediaDRM remained the same for First install, Work Profile, and Multiple Users on the OnePlus 8T

• Fingerprint V5 Optimal remained the same for the First install and Parallel Space on the OnePlus 8T

• MediaDRM and Fingerprint V3 & V5 Optimal remained the same after Reinstall on Redmi Note 10 Pro

• Fingerprint V5 Optimal remained the same after reinstalling for First install, Work Profile, and Parallel Space on OnePlus 8T

Changed (= bad):

• Fingerprint V5 Optimal changed for First install and Island App

• Fingerprint V5 Optimal changed after a Factory reset on the OnePlus 8 Pro

• Fingerprint V5 Optimal changed in Second Space on Redmi Note 10 Pro

• MediaDRM changed in Parallel Space on the OnePlus 8T

• Fingerprint V5 Optimal changed in Work Profile and Guest User on OnePlus 8T

Other:

• FingerprintV3 Optimal was better than Fingerprint V5 Optimal for the emulator

• MediaDRM was different on Emulator 1 and Emulator 2 (both on the same Windows machine)

Based on the observations, Fingerprint V3 and V5 Optimal failed in many multi-instance fraud scenarios compared to MediaDRM. From these tests, we can conclude that MediaDRM is the better one.

Analyzing raw data

To quantify the results, we took our data, evaluated the behavior of those IDs, and came up with the most suitable ID based on the data. Remember that our data may be skewed and not representative compared to the devices of your user base.

Two weeks of data collection

We took two weeks of our freeRASP data and analyzed them. As the period is relatively short, we assume there are only so many reinstallations. Again, beware that we deliberately chose this window without any research regarding the real reinstall rate, which may differ based on the category/use case of the specific application.

Below, you can see the number of unique values for each ID and the number of unique device models captured in this data.

AndroidID: 13 402 601

FingerprintV3: 22 525 265

MediaDRM: 13 285 081

InstanceId: 13 740 706

Distinct device models: 14 175 (i.e., Pixel 4, SM-G973N, ONEPLUS A5000, LG-H930, …)

At first glance, we noticed the number of FingerprintV3, which is much higher than the numbers of the other IDs. This could be caused by the behavior of the FingerprintV3, which changes whenever users change some of the 32 observed fingerprinting signals.

How are the IDs related?

After that, we looked at the co-occurrence of the IDs to see the relation between them.

How to read the table below: One AndroidID has 1.00557 unique MediaDRMs, and 0.54% of unique AndroidIDs have more than one MediaDRMs.

ID collisions: Same ID but different device

Based on the data, we can’t say what a “different device” is (as we are still looking for the “best” identifier).

Let’s look at how many models per ID there are on average. Remember that it is desirable for us to have the least number of collisions (distinct devices with the same ID) — we expect the IDs to have only one associated model. A quick glance over the table below will tell us there truly are some discrepancies.

The Findings

Based on the data analysis, we can state the following:

• FingerprintV3 has too many values compared to other IDs, making it less useful in our scenario.

• One AndroidID/MediaDRM/InstanceID usually has more FingerprintV3s.

• AndroidId and MediaDRM are roughly 1:1; some MediaDRM instances have multiple AndroidIDs (more than AndroidId has MediaDRMs).

• In some cases, one AndroidID has multiple InstanceIDs (more often than MediaDRMs), similar to the relationship between MediaDRM and InstanceID.

• InstanceID is more bound to AndroidID than MediaDRM.

• AndroidID has only one model (with a tiny amount of outliers).

• MediaDRM usually has one model, but there are a few collisions (more than in the case of AndroidID).

• InstanceId falls somewhere in between the models.

Overall, the best of these identifiers seems to be AndroidID, followed by MediaDRM. InstanceId can also be helpful, but less so than AndroidID. FingerprintV3 is useless in our scenario. Since AndroidID changes after the reinstallation and is relatively easy to spoof, MediaDRM seems to be the most suitable for fraud detection.

However, MediaDRM seems to have quite a few collisions (based on our analysis of the models). We have discovered that the collisions occur most often with devices of the same manufacturer (i.e., devices of the same manufacturer are much more likely to have the same MediaDRM than devices of different manufacturers). Here are some numbers for you to get an overview:

• 0.005% of MediaDRMs have more than one manufacturer

• 0.55% of MediaDRMs have more than one model of the same manufacturer

• The mean number of manufacturers per MediaDRM: 1.000085

• The mean number of models of one manufacturer per MediaDRM: 1.006362

Can we improve MediaDRM?

After many attempts (that we won’t elaborate here), we have tried experimenting with a combination of MediaDRM+model as a potential ID.

Example of combined MediaDRM+model of some Google Pixel 4: e3af1aa4dacb6b6637846488b511e7643c6ac20b65c95baad164b122ecb036b6+Pixel 4

Below is the same table of co-occurrences as above, now containing relations with MediaDRM+model:

We can see that the MediaDRM+model behaves better than the original MediaDRM — each MediaDRM+model has lower number of other IDs associated with it, meaning that we have avoided a few collisions (even though we cannot quantify that amount exactly, but the minimum bound is estimated by the MediaDRM — MediaDRM+model numbers).

While making the ID as a combination of two characteristics, we might run into an issue with one device having more IDs. However, this should not be the case with the MediaDRM+model, as one device should have only one model associated with it (i.e., one physical unit of Google Pixel 4 phone should always have only and only model name “Pixel 4”).

Therefore based on the data, we suggest using a simple combination of MediaDRM and device model as an ID for the examined case of fraud detection.

Summary

We’re tackling a challenge in mobile device identification — how to block fraudster devices without compromising user privacy. Mobile app owners face issues with users evading payments and exploiting bonuses through multi-instancing — reinstalling the app multiple times. Unreliable device IDs make it tough to identify persistent bad actors. Our findings recommend prioritizing MediaDRM over device fingerprinting (or even better combination of MediaDRM and device model) for effective blocklisting. Don’t forget to enhance security with layers like AppiCrypt, RASP, and KYC solutions. Every scenario is unique, so for tailored guidance, contact Talsec security experts at info@talsec.app.

Written by Dáša Pawlasová, Matúš Šikyňa, and Tomáš Soukal

Think Security: Our Take on a Leading React Native Boilerplate

In today’s digital landscape, mobile apps are not just about functionality—they’re also attractive targets for fraud and data theft. Security has become a fundamental part of app development, especially for apps handling sensitive user information. This article introduces a powerful option for app developers concerned with security: combining Ignite by Infinite Red, a leading React Native boilerplate, with freeRASP from Talsec—a free RASP solution—alongside other solutions to build secure and scalable apps.

React Native Secure Boilerplate: https://github.com/talsec/react-native-boilerplate

Ignite by Infinite Red

Ignite by Infinite Red is a robust React Native boilerplate featuring a CLI, component generators, and more. With over 12.2K GitHub stars, Ignite supports both Expo and bare React Native projects. It’s TypeScript-ready, utilizes MobX for state management, React Navigation for routing, Apisauce for REST APIs, and Jest for testing.

React Native's core features, such as Flipper, Reactotron, and Expo support, are enhanced by Ignite, which streamlines their use by providing pre-configured setups and simplifying integration. It also eases state management with MobX and ensures smooth state restoration by incorporating AsyncStorage with MST.

Ignite’s CLI can be accessed using npx for an always-updated version. You can create a new project with: For vanilla React Native: npx ignite-cli new newApp For Expo-powered projects: npx ignite-cli newApp –expo

Why Another Boilerplate?

Unlike other boilerplates that focus mainly on speed or provide a basic setup, this one is built for developers creating apps in high-risk industries like finance, healthcare, and e-commerce, where security is critical. The Ignite + freeRASP solution provides real-time protection against threats such as code tampering and unauthorized access, addressing vulnerabilities that standard setups often overlook. It’s designed to safeguard sensitive data and offer enhanced security for fraud-prone apps.

Disclaimer: Other solutions, such as paid options or even DIY approaches, may be suitable depending on your needs.

freeRASP: Adding Security to the Boilerplate

freeRASP is a lightweight Runtime Application Self-Protection (RASP) solution that provides real-time protection against a variety of threats. It’s built for easy integration and allows your app to react to detected risks automatically, like jailbreaking, tampering, or reverse engineering. Whether your app handles sensitive data or operates in an environment prone to fraud, freeRASP offers security features for post-launch protection and doesn't require external infrastructure, making it an accessible choice among several RASP options.

Key Advantages of freeRASP

• Real-time Threat Reaction: Through a comprehensive API, freeRASP can immediately respond to detected attacks and security threats, providing dynamic protection for your app.

• Ease of Integration: The solution features a simple download and installation process, complemented by clear source code snippets, ensuring a smooth integration experience.

• Minimal Performance Impact: freeRASP is designed to be lightweight, which means it provides robust security without compromising the app’s performance or user experience.

• Weekly Security Reports: freeRASP sends out regular email reports that detail the security status of your devices and the integrity of your app, helping you stay informed about potential vulnerabilities.

• Compliance with OWASP MASVS V8: It meets the OWASP MASVS V8 standards for resiliency against reverse engineering, ensuring your app is protected against common reverse engineering threats.

How RASP Works

RASP is designed to detect and respond to threats in real-time. Here's a breakdown of how RASP solutions like freeRASP typically work:

• Runtime Monitoring: Constantly checks for anomalies such as debugging attempts, code injections, or use of hooking frameworks like Frida or Xposed.

• Periodic Scans: In addition to real time monitoring, freeRasp schedules periodic scans that run deeper into the app to check for irregularities and tampering.

• Real-Time Responses: This enables Rasp to immediately take action against security breaches. Using predefined callbacks the app can be programmed to perform specific actions, such as alerting the user, restricting access to sensitive functionality, or even shutting down the app entirely.

• Reporting and Alerts: freeRASP also compiles detailed weekly reports that summarize the security status of the app. These reports provide insights into any detected vulnerabilities, unauthorized access attempts, or security breaches. Developers can use this data to track trends in threats and take proactive steps to address vulnerabilities before they become serious problems.

freeRASP Features

• Rooted or Jailbroken Devices: Protects against unauthorized access from tools like su, Magisk, unc0ver, check1rain, and Dopamine.

• Reverse Engineering: Prevents attempts to analyze or manipulate your app’s code.

• Hooking Frameworks: Detects and blocks frameworks like Frida, Xposed, and Shadow.

• Tampering and Repackaging: Identifies and responds to unauthorized modifications or repackaging.

• Untrusted Installations: Prevents installations from unofficial sources or app stores.

• System VPN control: VPNs can obscure the user’s actual IP address and route data through servers potentially under external control, which might interfere with geographical restrictions and bypass network security settings.

• Developer Mode control: Allows deeper system access and debugging capabilities that can bypass app security measures.

For more detailed information on these checks and their significance, visit the freeRASP docs.

freeRASP + Ignite: Combining Speed with Security

Integrating freeRASP with Ignite is straightforward and ensures your app is fortified against real-world security threats. Ignite accelerates development, while freeRASP delivers critical security features that safeguard your app. Integrating freeRASP with Ignite involves a few straightforward steps. For detailed instructions, check out our GitHub repository and Medium article.

1. Install the freeRASP Package: Add the package to your project using yarn with yarn add freerasp-react-native. For iOS, run Pod install.

2. Configure freeRASP: Set up the necessary fields (e.g., package name, certificate hashes) in your configuration file.

3. Set Up Threat Reactions: Define how your app should respond to detected threats by creating an object mapping threat types to response functions.

4. Initialize freeRASP: Use the provided custom hook to start threat detection with your configurations and reactions.

If you are interested in knowing additional details you can refer to the freeRASP documentation.

Build Your "Hello World" Project

With a brief outlook on how to configure freeRASP you might want to get a project up and running. Let’s look at how you might write code for a small “Hello World” project.

1. Begin with creating a react native project using Ignite. Use the following commands to start your app:

Init Ignite project via CLI:
$ npm install -g ignite-cli
$ ignite new HelloWorldApp

1. Install and configure freeRASP: First, create a configuration file named ‘freerasp.config.js’, where you will define your app's security and threat response settings. After that, use the useFreeRasp custom hook to initialize freeRASP. Here’s an example:

import { useFreeRasp } from 'freerasp-react-native'

1. Combine all the elements:

import React, { useEffect } from 'react';  
import { Text, View, Alert } from 'react-native';  
import { useFreeRasp } from 'freerasp-react-native';  
import freeRaspConfig from './freerasp.config';  

const App = () => {  
  useFreeRasp(freeRaspConfig, threatResponses); 

  return (  
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>  
      <Text>Hello, World! Welcome to Ignite + freeRASP!</Text>  
    </View>  
  );  
};  

export default App;  

const threatResponses = {  
  privilegedAccess: () => Alert.alert('Threat detected', 'Privileged access detected!'),
  debug: () => Alert.alert('Threat detected', 'Debugger detected!'),
  simulator: () => Alert.alert('Threat detected', 'Simulator detected!'),
  appIntegrity: () => Alert.alert('Threat detected', 'App integrity issue detected!')  
};  

There you have it, you've now successfully built your first Ignite + freeRASP project with just a few simple steps. More importantly, with just a few lines of code, you've fortified your app against major security threats. This is a significant achievement because it allows you to implement strong security measures without needing to dive into the complexities of cybersecurity. With freeRASP, you can integrate a strong protection layer into your app, providing a safer experience for users. For those looking for even more extensive coverage, paid RASP solutions are also available.

Best Practices

You might have secured your app with RASP but now it’s your turn to play a part. As a developer it is essential to follow best practices when building web or mobile applications to ensure your app is completely secure, here are a few tips:

1. Secure Data Transmission

Always use HTTPS for secure communication between your app and server. Implement SSL pinning to prevent man-in-the-middle attacks.

2. Code Obfuscation

Ensure you always build for production so that Metro Bundler automatically minifies your JavaScript code, making it harder for attackers to reverse-engineer. Additionally, for Android, enable code obfuscation at the native level by setting the ‘minifyEnabled’ and ‘shrinkResources’ flags in your build.gradle file. This process further protects your code from being easily understood or modified.

3. Authentication

Ensure that strong authentication mechanisms, such as OAuth or JWT (JSON Web Tokens), are used to verify user identities.

4. Secure Storage

Never store sensitive data directly on the device. Use encrypted storage and secure system features like Keychain (iOS) and Keystore (Android).

5. Third-Party Libraries

Always vet third-party libraries for security risks. Make sure they are actively maintained and regularly updated.

Summary

In 2024, mobile app security is not optional—it’s essential. By combining Ignite for rapid development with freeRASP for runtime security, you can build a secure and scalable React Native mobile app with minimal effort. Developers can take advantage of freeRASP’s real-time threat detection and regular security reports to keep their apps safe without worrying about complex security implementations.

With a focus on fraud-prone industries and apps handling sensitive user data, this boilerplate provides everything you need to get started quickly while ensuring your app is protected against real-world threats.

Why wait? Explore freeRASP and other RASP options to secure your app today!

In an increasingly interconnected world, the need for robust application security has never been more critical. Capacitor, with its remarkable ability to build cross-platform apps using web technologies, empowers developers to create stunning applications with ease. However, as the capabilities of our apps grow, so does the importance of safeguarding them against a myriad of potential threats.

With a native runtime such as Capacitor, it is fairly easy to turn any web app into native apps for both Android and iOS. You can quickly use the native APIs and access common device functionality, which is awesome, but at the same time, it adds another level of complexity because when you access native APIs, you are imposing yourself to native security issues as well. And trust me, you don’t want to underestimate these challenges.

As a practical example, consider one of the most common security concerns: reverse engineering. Mobile apps are typically distributed in formats like APK (for Android), AAB (Android App Bundles), or IPA (for iOS). These distribution files contain bundled JavaScript code essential for the application’s functionality.

Despite attempts to obfuscate the code through minification and adhering to industry standards like OWASP MASVS (Mobile Application Security Verification Standard), a person with the necessary knowledge can still extract your code with relative ease. There are even utilities like JSTool that can effectively reverse the minification and reveal the original code, potentially exposing sensitive keys and API calls. Afterwards, it’s all in the hands of the attacker.

Successful attacks like these may lead to loss of revenue, exposure of sensitive data, damage to the brand and reputation or leaked intellectual property. And that’s where we want to help you.

What is freeRASP?

Talsec freeRASP is a freemium mobile security SDK designed to make app protection straightforward and accessible. It offers robust protection against a range of threats and is supported on both Android and iOS platforms. freeRASP also provides customized modules for a number of multi-platform tools, now including Capacitor.

From a developer’s perspective, freeRASP acts as an additional protective layer, simplifying the handling of certain attack vectors. This allows you to focus on other critical aspects of your app while safeguarding your users. freeRASP can detect and inform you about various attack scenarios, including reverse engineering, repackaging, cloning attempts, and much more.

Join us as we explore how freeRASP integrates with Capacitor, helping you defend your apps against attacks and vulnerabilities, and ultimately, ensuring your users’ safety. Say hello to enhanced security and peace of mind for your Capacitor apps — let’s dive in.

Why Do You Need RASP?

Mobile app security is a complex challenge that goes beyond traditional security measures like encryption and certificate pinning. Attackers constantly seek vulnerabilities in your app that may not be immediately obvious. A single security breach can have severe consequences for your reputation and user trust.

The need for Runtime Application Self-Protection (RASP) solutions has grown significantly with the rise of mobile technologies. While there are several security libraries available, freeRASP stands out by offering comprehensive protection across various attack vectors.

Based on our experience, a selection of the most common attacks include:

• App repackaging and cloning

• Re-publishing of tampered apps

• Running the App in compromised OS environments (rooted/jailbroken OS, hooking app during runtime, emulators)

freeRASP is designed to detect and mitigate these types of attacks, providing an extra layer of defense against evolving threats.

Integrating freeRASP with Capacitor

Now, let’s dive into the process of integrating freeRASP with the Capacitor platform. You can always find up-to-date integration manual along with detailed description of configuration in our GitHub Integration Guide.

Step 1: Install the Plugin

To get started, install the capacitor-freerasp plugin:

$ npm install capacitor-freerasp
$ npx cap sync

Step 2: Set Up Dependencies

For Android, ensure that your project’s minimum SDK level is set to 23. Update your variables.gradle file accordingly:

ext {
    minSdkVersion 23
    compileSdkVersion 33
    // ...
}

Step 3: Setup Configuration and Callbacks

Import freeRASP in your app’s entry point file:

import { startFreeRASP } from 'capacitor-freerasp';

Configure freeRASP by providing the necessary settings. You’ll need to specify configuration for both Android and iOS, as well as common configuration options. Here’s a sample configuration:

const config = {
  androidConfig: {
    packageName: 'com.yourapp.package',
    certificateHashes: ['yourSigningCertificateHashBase64'],
    supportedAlternativeStores: ['storeOne', 'storeTwo'],
  },
  iosConfig: {
    appBundleId: 'com.yourapp.bundle',
    appTeamId: 'yourTeamID',
  },
  watcherMail: 'yourEmailAddress@example.com',
  isProd: true,
};

Additional Note About Obfuscation

To enhance security, consider obfuscating your app’s code. Obfuscation makes it harder for attackers to reverse engineer your app and disrupt freeRASP’s operations. You can enable code minification and obfuscation for Android in your build.gradle file:

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

Security Report

With this weekly summary, you get insights into your app’s security state, including detected threats and device characteristics. By keeping an eye on these reports, you can proactively address security issues before they become too severe and make your app even safer for users. If you are curious how such report looks like, take a look at the screenshot below 👇.

Commercial Versions (RASP+ and More)

While freeRASP offers a robust free version, Talsec also provides commercial versions like RASP+ with advanced features and support. These versions offer additional protection, including API protection, App Integrity Cryptogram (AppiCrypt®), security hardening, and more.

RASP+ allows easy-to-implement API protection and App Integrity verification on the backend to prevent API abuse from:

• Bruteforce attacks

• Botnets

• API abuse by App impersonation

• Session-hijacking

• DDoS

It is a unified solution that works across all mobile platforms without dependency on external web services (i.e., without extra latency, an additional point of failure, and maintenance costs).

Learn more about commercial features at talsec.app.

Finally, stay protected before it’s too late 😎

If you read through the whole article, thank you. Maybe now it’s time to check out freeRASP. It’s free, so there’s nothing to lose and who knows, maybe it will save you from a couple of sleepless nights.

We’d be happy to read your thoughts in the comments below 👇 or in one of our GitHub repos 📄.

Written by Tomas Psota, developer @ Talsec

Introduction

In today’s mobile app ecosystem, ensuring your app is secure from piracy, tampering, and sideloading is more important than ever. With unofficial app stores and third-party platforms on the rise, developers face the risk of their apps being stolen, modified, or misused, often leading to revenue loss, security breaches, and reputation damage. One simple but effective measure to safeguard your app is enforcing install source restrictions, ensuring it only runs if downloaded from official stores like Google Play or the Apple App Store. This article explores how you can implement these checks and why it’s crucial for app security.

How Unauthorized Installs Lead to Vulnerabilities

Distributing an app through unofficial channels opens the door to numerous security threats, many of which could have devastating consequences for both the developer and users. Unauthorized installs can lead to significant breaches in security for several reasons:

1. Tampered versions of the app

2. Lack of official updates and security patches

3. Data leaks and privacy concerns

4. Exploits for ads or in-app purchases

5. Gateway for broader attacks

One common scenario is that the app being installed has been tampered in order to skip verifications of some kind or in order to add malicious code to it. As an example, an attacker can use apktool to decompile the apk:

apktool d mynotsosecureapp.apk

This gives back a smali version of the app that can be changed later on. Think of smali code like an assembly-like language that is a low-level representation of the compiled Java code. That can be modified by maybe adding a key logger function of some sort.

.method public onCreate(Landroid/os/Bundle;)V
    .locals 1
    .param p1, "savedInstanceState"    # Landroid/os/Bundle;

    .prologue
    invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

    # Call malicious keylogger here
    invoke-static {}, Lcom/malicious/Keylogger;->logKeyStrokes()V

    # Original code here

.end method

Than is as simple as repacking the app with apktool

apktool b mynotsosecureapp.apk

and then resign the apk

jarsigner -keystore fake.keystore mynotsosecureapp.apk fakealias

This high-level example shows how dangerous it can be to install an app like this for both developer and user. Users who unknowingly download these tampered versions may be exposed to malware, spyware, or data-stealing mechanisms that compromise their personal information. This type of unauthorized access could include reading sensitive files, intercepting user data, or even hijacking user accounts. Developers can be harmed both in terms of their reputation and earnings. Modified app versions may disable ads, unlock premium features for free, or provide unauthorized access to paid content.

How to Check to Install Sources in Your Mobile App

One basic strategy is to check the install source every time the user launches the app and react accordingly.

Let’s see a quick and easy example using Flutter. Keep in mind that we will write some native code for Android and iOS, so you can use the same code if your app is native only or if you want to use it in any other framework.

So first of all, let’s create a new Flutter project with flutter create check_install_source. You can remove the main.dart file entirely and replace it with the following, starting with the necessary imports and the classi main declaration:

import 'dart:async';
import 'dart:io';

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

void main() {
  runApp(const MaterialApp(home: MyApp()));

Then we can create a MyApp class

class MyApp extends StatefulWidget {
  const MyApp({super.key});

  @override
  MyAppState createState() => MyAppState();
}

In the actual MyAppState we can implement a simple build method and the initState :

class MyAppState extends State<MyApp> {
  static const platform = MethodChannel('flutter_app_restrictions');

  @override
  void initState() {
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Flutter Install Source Restriction'),
      ),
      body: const Center(
        child: Text('App is running...'),
      ),
    );
  }
}