Mobile Banking Security: A Comprehensive Guide for Managers

When a regional bank suffered a significant breach through its mobile banking app, it wasn't just its balance sheets that took a hit - it was its customer trust and market position. 

Security is a widely discussed topic in all industries. However, it’s especially acute in mobile banking, since her people's sensitive data are at risk. In this digital age, a single vulnerability can erode the hard-earned trust that takes years to build.

As a software developer at SumatoSoft who deals with mobile banking solutions and finance software development, I know the amount of effort developers put into mobile banking security. 

In this article, I will share my expertise and knowledge of developing software solutions for the banking and finance sector for 6 years. I'll share insights on the scale of security challenges, identify the most common threats, and outline practical strategies we use to protect mobile banking applications.

Is Mobile Banking Security Really at Risk?

Numbers speak louder than words, so refer to some reports and news sources about mobile banking security and more common security issues.

- In 2021, new mobile banking Trojans were detected 97,661. 

- According to the Incident Response and Data Breach Report, financial services was the second most targeted sector, accounting for 14% of security incidents we responded to.

- According to the same report, mobile is the third most popular category of cyber attacks globally. 

- The Equifax data breach compromised the sensitive personal and financial data of over 40% of the U.S. population, resulting in a $700 million fine.

- According to the Cyber Security Report 2020 by the National Technology Security Coalition, in 2020, there was a 50% increase in attacks against smartphones, with mobile banking Trojans being a common threat. 

- Zimperium's 2023 Mobile Banking Heists Report uncovered that 29 malware families targeted 1,800 banking applications across 61 countries. 

Mobile Banking Security Common Threats

First of all, it must be highlighted that both users and developers are responsible for the proper security of users' personal data. Users must be cautious and informed about secure practices, while developers are tasked with ensuring the robustness and integrity of mobile banking applications against technical vulnerabilities and exploits.

Still, mobile banking app developers are capable of handling some of the user-responsible threats. I’ll explain the exact ways later. Here are two categories of most common mobile banking security threats. 

User-Responsible Threats

Phishing and Smishing

Phishing and smishing are both types of cyber attacks aimed at stealing personal information via email (phishing) or SMS (smishing).

Attackers send an email / SMS where they impersonate legitimate entities, such as banks, social media platforms, or government agencies and ask to follow the link to a fake website or to call a phone number. Then, they trick individuals into providing personal information, such as passwords, credit card numbers, or social security numbers. 

Data Leakage

Data leakage in mobile banking can occur when users inadvertently expose confidential information through unsafe handling of their personal data. This can take place in various forms, such as saving sensitive information like login credentials in unsecured note apps, sharing screen captures containing private data on social media, or even allowing excessive app permissions beyond what is necessary for the app's function.

These lapses can provide cybercriminals with unauthorized access to financial details, leading to potential account breaches and financial loss. Users must be cautious with how they manage and share their personal information to mitigate the risk of such exposures.

Device Loss or Theft

The risk here comes from someone gaining physical access to a user's mobile device, which may contain accessible mobile banking apps and financial information. If a device isn't properly secured with a strong password, biometric locks, or encryption, it can lead to unauthorized transactions and access to personal banking data.

Using Unsecured Wi-Fi Networks

Conducting mobile banking transactions over public Wi-Fi can expose users to the risk of cyber eavesdropping. Hackers can intercept unencrypted data transferred over these networks, gaining access to account details and login credentials.

Rooting or Jailbreaking Devices

Altering the operating system of a mobile device to remove manufacturer or network carrier restrictions can introduce security vulnerabilities. This process often disables built-in security features, making the device - and any mobile banking applications on it - more susceptible to malware and cyber-attacks.

Developer-Responsible Threats

Mobile Malware and Trojans

These are malicious software programs specifically engineered to target mobile devices.

For example, a banking Trojan might disguise itself as a legitimate banking app. Once installed, it operates in the background, monitoring the user's activities and stealing bank account credentials when they are entered. Some Trojans can even initiate fraudulent transactions directly from the infected device.

App-based Vulnerabilities 

These include security gaps within the app that hackers can exploit.

An example might be an SQL injection flaw, where attackers input malicious SQL statements in the app's input fields to gain unauthorized access to the database.

Another example is cross-site scripting (XSS) vulnerabilities that allow attackers to inject malicious scripts into web pages viewed by other users.

Man-in-the-Middle (MitM) Attacks

When data is transmitted from the mobile banking app to the bank's servers, it can be intercepted by attackers if not properly encrypted. Developers must ensure secure transmission to prevent data from being intercepted during transit.

Insecure Data Storage

This pertains to the improper handling of data within the app.

For instance, an app might store sensitive information like login credentials, financial transaction records, or personal identification numbers in plain text or in a manner that's easily decryptable, making it vulnerable if the device is compromised.

Fake or Rogue Banking Apps

These are illegitimate applications developed to look and feel like real banking apps. Users who mistakenly download and install these apps end up providing their banking credentials directly to the cybercriminals. The threat here is the deception and the subsequent unauthorized access to the user's bank account.

UI Redress/Clickjacking Attacks

In such attacks, the app allows a hidden invisible layer to be placed on top of the banking application. The user believes they are clicking on the legitimate buttons or links in the app, but they are actually interacting with this hidden layer. This can result in users unknowingly granting permissions, initiating transactions, or revealing sensitive information. 

An example could be a fake "Accept" button overlaid on top of a genuine banking app's interface, which instead triggers a malware download or data submission to a malicious source.

So, we know the threats, it’s time to speak about what is possible to do with them and what it means to “develop a robust mobile banking security”. 

How to Ensuring Robust Mobile Banking Security

Before moving to the well-known practices and my personal recommendation, I want to refer to the Cambridge Savings Bank, a US bank with over 185 years of presence on the market. According to its document with security procedures to enhance online protection, the bank uses the following procedures to enhance mobile banking security: 

- multi-factor authentication - password and name are usually the first factor, while a one-time password (OTP) or a token sent to a specific user device serves as the second factor;

- a strong password as a requirement - the length from 8 to 24 symbols, combined letters, numbers and symbols; 

- dual control - two users together only can initiate fund transfers. One initiates, another approves; 

- settings limit - it implies limits to cash withdrawals, transfers or payments; 

- activity reporting - it includes transactions, login attempts, activity times, etc.; 

- alerts -  provide information about transactions that may require the user’s attention.

In continuation, there are three categories of measures to examine: 

- Must measures - any banking software must implement these measures by default. It’s just pointless to release the app without implementing these mobile banking security measures. 

- Recommended measures - some non-obligatory, but highly useful measures. 

- Addressing user-responsible threats - there are some methods developers can implement to prevent security breaches on the user side. We talk about them here. 

Must-Measure to Secure the App

Must #1. Strong Authentication and Authorization Mechanisms

This is the first recommended procedure from Cambridge Savings Bank, and it’s fully valid. Multifactor authentication (MFA) methods, such as one-time passwords sent via SMS or email, biometric authentication (fingerprint or facial recognition), and security tokens are great ways to enhance mobile banking security.

The authorization model should be strict, preferably using role-based access control (RBAC) to limit access based on user roles. It means that authorization ensures that once authenticated, users can only access features and data for which they have permission, based on predefined roles within the banking application.

Threats it addresses: 

- Phishing and smishing. Provides robust defense against attacks aiming to steal login credentials.

- Mobile malware and trojans. Helps block unauthorized access attempts even if credentials are compromised.

- Device loss or theft. Secures user accounts by requiring authentication factors that a thief is unlikely to possess.

- App-based vulnerabilities. Offers an added security layer to minimize risks associated with software flaws.

Must #2. Secure Data Transmission

This measure involves encrypting data as it moves between the mobile banking app and the bank's servers, typically using protocols like TLS (Transport Layer Security). Encryption ensures that even if data is intercepted during transmission, it remains unreadable and secure from unauthorized access.

Threats it addresses:

- Man-in-the-middle attacks. Prevents attackers from eavesdropping or tampering with data during transmission.

- Phishing and smishing. Helps safeguard sensitive information even if users are tricked into entering data on a compromised connection.

Must #3. Data Encryption

Data encryption ensures that even if unauthorized parties access the data on the user’s device or a backend system, they cannot decipher it without the corresponding decryption key. The process involves converting plain text data into an unreadable format, known as ciphertext, using an encryption algorithm and a secret key. When the data needs to be accessed, it is decrypted using the corresponding decryption key, turning it back into its original, readable format.

One of the most robust encryption algorithms recommended for securing mobile banking data is the Advanced Encryption Standard (AES) with a key size of at least 256 bits. AES is a symmetric key encryption algorithm, which means it uses the same key for both encryption and decryption processes. It's widely recognized for its strength and efficiency, making it suitable for protecting financial information.

AES-256, in particular, is favored for its high level of security and is used by governments and security experts worldwide to safeguard classified information.

Threats it addresses:

- Insecure data storage. Protects stored data from being exploited if the device or server is compromised.

- Device loss or theft. Ensures that data on lost or stolen devices cannot be accessed by unauthorized users.

Must #4. Secure Coding Practices

Adhering to secure coding practices involves writing code for mobile banking apps in a way that anticipates and mitigates potential security vulnerabilities. This includes validating all inputs, securely managing sessions, and avoiding common coding errors that could be exploited.

Threats it addresses:

- App-based vulnerabilities. Reduces the risk of security flaws within the app that could be exploited by attackers.

- UI redress/clickjacking attacks. Prevents attackers from manipulating the app's user interface to deceive users into performing unintended actions.

- Mobile malware and trojans. Helps ensure that the app does not contain security gaps that could be exploited to introduce malicious software.

Must #5. API Security

The way to secure the API: 

- use API keys, tokens, or other authentication mechanisms to control access.

- Ensure that all API calls are made over HTTPS.

- Implement rate limiting to prevent abuse. Rate limiting controls how many requests a user or IP address can make to an API within a given time frame. It helps prevent abuse and ensures service availability for all users. A "good" rate limit depends on your application's specific use case and capacity. For example, an API might allow 1000 requests per hour per user for a general endpoint but limit more resource-intensive operations to 100 per hour. 

Threats it addresses:

- Man-in-the-middle attacks. Ensures that data transmitted between the app and server cannot be intercepted or altered.

- Mobile malware and trojans. Protects against unauthorized access and data exfiltration by securing endpoints.

Must #6. Security Testing and Code Reviews

This practice includes conducting thorough security testing, including static application security testing (SAST), dynamic application security testing (DAST), and penetration testing, to identify and fix vulnerabilities. Regular code reviews that follow main principles of security testing by security experts can also help identify potential security issues early in the development process. The goal is to uncover issues such as injection flaws and cross-site scripting (XSS).

Threats it addresses:

- App-based vulnerabilities. Identifies and allows for the correction of coding errors that could be exploited.

- UI redress/clickjacking attacks. Helps discover vulnerabilities that could allow attackers to manipulate the user interface.

Must #7. Incident Response Plan

An incident response plan is a documented, structured approach for handling security breaches, cyberattacks, or any other incidents that could potentially compromise information security. It includes steps for identifying, containing, and mitigating the issue, as well as notifying affected users if their data has been compromised.

An effective plan typically includes:

- Preparation. Training team members and preparing the tools and communication channels needed for an effective response.

- Identification. Detecting and identifying the incident as quickly as possible.

- Containment. Limiting the scope and impact of the incident to prevent further damage.

- Eradication. Finding and eliminating the root cause of the incident, and removing affected systems from the production environment if necessary.

- Recovery. Restoring and returning affected systems and services to a fully operational state.

- Lessons learned. Reviewing and analyzing the incident and the response to it, then using this analysis to strengthen future defenses and response plans.

Here is an example scenario: 

Threats it addresses:

- All identified threats. Provides a structured approach to responding to any security incidents, thereby reducing potential damage and recovery time.

Recommended Strategies

Recommended #1. Implement Secure Session Handling

Secure session handling involves the use of secure, unique session identifiers and ensuring that session tokens are transmitted securely. JSON Web Tokens (JWT) are a common format, which can securely transmit information between parties as a JSON object.

Implementing timeouts for sessions and requiring re-authentication for sensitive operations can further enhance security. This practice prevents unauthorized access to a user's session, even if their device is temporarily unattended or compromised.

Threats it addresses:

- Session hijacking. By securing session tokens and implementing robust session management practices, the risk of an attacker taking over a user's session is greatly reduced.

- Phishing and smishing. Secure session handling mechanisms can help mitigate the impact of phishing attacks by limiting the usefulness of session tokens that might be phished.

Recommended #2. Patch Management and Dependency Updates

Regular updates of the application and its dependencies to the latest versions protect against known vulnerabilities. The use of tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot can automatically scan your project's dependencies for known vulnerabilities and suggest updates or fixes. Moreover, there are multiple open websites that regularly publish the latest identified cybersecurity vulnerabilities. The most reputable are:  

- Common Vulnerabilities and Exposures (CVE);

- National Vulnerability Database (NVD);

- OWASP Top 10.
https://sumatosoft.com/blog/mobile-banking-security-for-managers