Accedia’s best mobile app security practices

Today, smartphones are all around us, and so are the mobile apps within them. In recent years, they have even outpaced traditional web apps (by 50% in the last two years alone), with nearly 90% of the average user’s time spent on a mobile device being inside of an app, as opposed to a website.

With such a rise in popularity, however, there is an aspect of mobile development which is quite often overlooked - security. Mobile app security has very similar implications to the ones over at the web development front, with a few distinct exceptions. Here, at Accedia, we value security among all else and put a lot of emphasis on it, always striving to provide the most secure solutions possible for our clients.

In this blog post we will share some mobile app security practices that we follow during our development process.

Backend security

A very smart developer once coined the paradigm that one’s frontend is just as secure as their backend is. That is most definitely the case for mobile apps too. Today, being more connected than ever, the backend is, often, the backbone of our mobile apps. We will start off with a couple of key practices that help us make our backend services and APIs as secure as possible, thus ensuring that so are the mobile apps that consume them.

Transport layer security (TLS)

Probably the most important aspect of backend security is communicating over a secure transfer protocol. Now, let's delve into why the HTTPS protocol using TLS is vital for mobile security.

Mobile apps often transmit sensitive information, such as login credentials, personal details, and payment data. Using TLS ensures that this data remains confidential and cannot be intercepted by malicious actors, such as hackers. TLS also guarantees that the data received by the mobile device is unchanged during transit. Any tampering with the data would be detected, preventing attackers from modifying the content.

Additionally, TLS provides a mechanism for verifying the identity of the server through digital certificates. This ensures that the mobile device is communicating with a legitimate server and not a malicious one trying to impersonate it.

Without TLS, attackers can intercept data transmissions between a mobile device and a server. They can then read or manipulate this data. TLS encryption prevents Man-in-the-Middle (MitM) Attacks by encrypting the data in transit. Handling user sessions properly in a mobile application is crucial for ensuring the security and privacy of sensitive information and restricting unauthorized access.

Authentication

Accedia’s best practices in mobile security always require users to log in with valid credentials (e.g., username and password) before granting access to sensitive data or functionality.

We always recommend also using secure session tokens to track sessions. This saves the users the annoyance of reauthenticating themselves on each separate interaction with the app in a secure manner. These tokens should be unique, unpredictable and have a short lifespan. To achieve longer-lasting sessions, the authentication process can be further extended to incorporate additional refresh tokens. They have a longer lifespan and can refresh the main access token periodically.

Database security

Backend applications often use databases to store data efficiently. These databases can be of various types, such as the relational SQLite, MySQL, PostgreSQL, or non-relational cloud-based solutions like Firebase Realtime Database, MongoDB or Amazon DynamoDB. The way they are accessed and queried is critical to the security of both the backend itself and, as an extension, the mobile application.

Query injection is one of the most common security vulnerabilities and occurs when an attacker manipulates a query sent to a database to perform unintended actions. The most well-known form of query injection is SQL Injection (SQLi) in SQL-based databases, but other types of query languages can also be targeted. "Smart" query injection is more sophisticated. It involves attackers using techniques that evade common security mechanisms and exploit vulnerabilities that are harder to detect and prevent.

To protect against smart query injection and maintain mobile application security, Accedia always uses the best practices available. For example, validation of all user inputs, ensuring they conform to expected formats and values, utilized parameterized queries or prepared statements when interacting with databases to prevent query manipulation and role-based access control. This ensures that the database user account used by the application has the least privilege necessary to perform its tasks.

Data encryption

Data encryption is yet another pinpoint of backend security. Sensitive data and, especially, passwords, should always be encrypted, so that even if someone were to access it, it would be rendered unreadable to them. There is a variety of libraries and services available to achieve this. One of the most common methods is salting all passwords, appending random string sequences to them and then hashing them all together, making each generated password hash unique and quite difficult to reverse engineer.

On-device mobile app security

Things here start to diverge from the web apps a little bit. All mobile apps are essentially limited and quite secured by the constraints enforced by the OS provider. Still, undergoing stringent mandatory store release QA process for each new version, there are a few things that is always a good idea to be careful with.

Database security, but mobile

Securing a local database in a mobile application is crucial to protect sensitive user data from unauthorized access or data breaches. In this aspect, Accedia’s mobile app security includes all the above-mentioned techniques against smart query injection, with the additional inclusion of encrypting the database file. As it’s hosted on-device and is more easily accessible than if it was hosted on a server in the cloud, we protect its contents by collecting and storing only the data that is necessary for the application's functionality.

Sensitive keys and secrets handling

Another "must" approach in mobile app security is storing encryption keys, API keys, secrets, credentials and all other sorts of sensitive data securely. We recommend avoiding hardcoding such sensitive data in the application’s code, and on devices in general, without a protection layer or facilitating a secure storage mechanism like Android's Key Store and Encrypted Shared Preferences or iOS's Keychain. Credentials, for Android’s key store, for example, should preferably be stored somewhere else entirely, far away from both the app’s codebase and even its source control.

Another good mobile app security practice includes setting up configurations, supplied during Continuous Integration/Continuous Deployment (CI/CD) via environment variables. By providing sensitive configuration data through environment variables, the risk of exposing it through the app's source control is greatly diminished. Thus alleviating any security concerns and making the app’s configuration more easily scalable in the process too. Those variables can also be periodically rotated to further reduce the risk. Additionally, clever auditing and monitoring of environment variable changes can be implemented inside the CI/CD pipeline to detect any unauthorized access or changes.

Biometrics

In our mobile security experience, it has been shown that biometrics are a valuable tool for enhancing authentication security in mobile applications. Biometric authentication leverages unique physical or behavioral characteristics of an individual to verify their identity. Biometric data, such as fingerprints, facial features, or iris scans, are unique to each person, making them difficult for attackers to forge or replicate. This uniqueness enhances the strength of authentication compared to traditional passwords.

Biometrics can help mitigate common password-related risks, such as password reuse, weak passwords and password leaks. They are typically tied to physical attributes or behaviors, making them a challenge to be exploited remotely. This adds an extra layer of security against remote attacks like phishing. As an additional benefit, users do not need to create and manage passwords, which can be a security vulnerability.

Code obfuscation

The executable of the app should always be as hard to read and decipher as possible. Here comes code obfuscation – the process of modifying the code behind said executable so that there is no longer a use for it to be read and examined but the functionality behind it remains intact. iOS apps are natively not as prone to reverse engineering as their Android counterparts. Thus, implementing obfuscation is optional, but there are various tools to accomplish this if the client so desires.

On the other hand, Java bytecode is quite fragile and more easily decompilable. Code obfuscation through a tool like the built-in ProGuard makes it so that if the app is decompiled by a malicious party, it would be much more difficult for them to understand the code, let alone reverse engineer it. Anyone motivated enough would still be able to get past this measure. However, it is highly advisable to take it as that would eliminate all the risk from the more trivial malicious efforts.

Simply hiding sensitive information 

For apps with sensitive data constantly being displayed on-screen, it might be wise to approach the situation by blanking out the screen’s contents in the recent app’s drawer. Additionally, you might require reauthentication with PIN/biometrics each time a sensitive screen is resumed. This is particularly useful in apps within the banking domain where keeping all on-screen information away from prying eyes might be detrimental to its security, even if the on-device security is largely on point.

Smart usage of analytics

A good practice that might sometimes help us identify malicious intent is simply monitoring our applications post-release, with clever use of event-tracking and observing other related metrics. Sometimes it might be quite easy to observe weird unnatural activity patterns, perhaps serving as an indication of botting.

Going the extra mile

In some specific scenarios, it might be worth going the extra mile and turning to more unconventional solutions.

One of the more interesting examples we’ve had was a client wanting to dramatically increase the security of their authentication process. They already used HTTPS, but the security implications were great, and they wanted to take every precaution possible.

We resorted to decoupling the authentication process from the app entirely, with the help of the OpenID Connect authentication protocol. Its largest benefit is that the entire process passes through a web view via multiple app redirects, using Single Sign On (SSO), rather than through the app itself, and is thus much harder to intercept.

Diving into some more specifics, this authentication flow is called Auth Code Flow + PKCE (Proof Key for Code Exchange). The PKCE (pronounced “pixy”) part of the approach creates a new code verifier on each session, which is then hashed (a process called “code challenge”) and sent over to the authentication server. Once the code challenge is received, the user is redirected to the login page where a typical token fetch request is made. Тhis time, however, the app sends the code verifier with it too. It is hashed on the backend and then compared to the initial code challenge that is saved. If there is a mismatch, it would mean that someone has been tampering with the authentication process and no tokens will be returned, leaving the user unauthenticated. This way the mobile app security is enhanced by preventing any possible tampering and potential leaking of sensitive credentials.

As an additional level of security, which is usually not necessary, the client decided to build their own encapsulated authentication server.

Mobile app security in enterprise solutions

In recent years, mobile devices have also brought in huge value for enterprise users in internal company applications. While the number of mobile devices continues to grow, they are still one of the largest security risks for organizations today.

Mobile device management (MDM) is a proven methodology that acts as a toolset used to provide corporations with workforce mobile software productivity tools and applications, all while keeping the data within them secure. It is a solution that facilitates software to provision corporate mobile devices with enrollment options for either full device management or a simpler work profile management, depending on the needs. Android devices have lagged behind iOS ones in this regard for a long time but in recent years they have caught up, offering enterprises more options than ever.

As a company that is taking security very seriously, here at Accedia we have integrated MDM into our workflow, and we strongly advise our clients to do so too.

Getting someone else's take on the matter

Even after all the above-mentioned practices are considered and implemented, it never hurts to bring in a second opinion. Usually, this is requested explicitly by our clients in the form of 3^rd party tools. Each of them often has a unique preference, depending on what they have incorporated within their portfolio. There is a variety of software on the market which can scan the whole application, be it with a manually provided executable, or even better – being directly integrated as a job right in the CI/CD pipeline for increased automation. Those scans can not only go thoroughly through the source code but through its external dependencies as well. These outputs detailed reports of all sorts of detected security vulnerabilities, separated by severity levels. This is a very advisable step to take, given that it’s an easy method to validate the taken security measures within the app. Additionally, it may bring to light some previously unnoticed security flaws before it’s too late.

Conclusion

In truth, there is no such thing as unbreakable security, and mobile app security is no exception. Cyber threats are not only everywhere, but they are constantly evolving too. A determined attacker will sooner or later find a way to get through even the most advanced systems. However, continuously updating and improving the security of our products and systems is extremely important as it allows us to stay ahead of potential threats.

In the blog post we touched on some of the key mobile app security aspects that we always strive to cover at Accedia. Of course, different clients may have completely different needs and potential security implications. In some scenarios, a custom-tailored mobile security solution would be best. Still, it will, in one way or another, always derive from precisely the above-mentioned basics.

Looking to build a secure mobile application? Make sure to contact our team and get a personalized consultation.