10 Methods to Address Threats in Mobile Banking Security

When a regional bank suffers a security breach through its mobile banking app, it’s customer trust that takes the heat rather than the balance sheets. 

Securing personal information is a sensible topic in any customer-centered industry. Banking takes a special place since it deals with finances, and even a small breach could give fraudsters hints on how to unlawfully obtain other people’s money. A single vulnerability can lead to a loss of trust that took years to build. 

I work as a software developer at SumatoSoft who deals with mobile banking solutions and finance software development. In this article, I will share my expertise and knowledge of developing secure 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

Firstly, I want to clarify an important point: 

Users must be cautious and informed about cyber threats and fraud tactics, while developers should secure the mobile application against known vulnerabilities and exploits. It is tempting to conclude that developers aren’t responsible for users’ poor-informed actions that make them fraud victims. However, this is not really true. 

It might seem controversial, but mobile banking app developers are capable of handling some of the user-responsible threats. 

How? I’ll explain it a bit later. First, we need to describe the treats in mobile banking.

Phishing and Smishing

Phishing and smishing are both types of cyber attacks that aim to steal 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. The user inserts sensitive information like credit cards, personal information, or passwords on a fake website, thus providing this information to fraudsters.

Unintentional Data Exposure

Data exposure occurs when a user unintentionally share their confidential information with fraudsters when, for example, users share their screen captures that contain sensitive information or provide excessive app permissions that allows the application to access sensitive information. Any confidential detail leads to potential account breaches and financial loss. 

Device Loss or Theft

One lost or stolen device could give access to a lot of financial and personal information if a device isn’t properly secured with a strong password, biometric locks, or encryption. 

Using Unsecured Wi-Fi Networks

Conducting mobile banking transactions over public Wi-Fi is one of the most reckless acts a person can commit since it exposes personal information through an unsecured network. Such actions open opportunities for a man-in-the-middle to steal the user’s personal information and use it later. 

Rooting or Jailbreaking Devices

Rootking and jailbreaking provides user with an excessive access that allows to override the restrictions and intall anauthorized apps. That opens the ways for malware, spyware, and viruses to exploit such priviliges to access information, perform anauthorized actions, or install harmful software. 

Developer-Responsible Threats

Mobile Malware and Trojans

These are malicious software programs specifically engineered to target mobile devices. Once installed, they operate 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 mobile apps that hackers can exploit. An example is SQL injection, where attackers input malicious SQL statements into the app’s input fields to gain unauthorized access to the database. Another example is Cross-Site Scripting (XSS), where vulnerabilities allow attackers to inject scripts into web views within the app to steal cookies, session tokens, or other sensitive information.

Man-in-the-Middle (MitM) Attacks

As we mentioned earlier, data transfer from bank’s servers to mobile banking applications could be intercepted by fraudsters that are called “man-in-the-middle”. These cybercriminals can decipher the data and access to the sensitive information that is circulated between the bank and the user. 

Insecure Data Storage

An app might store sensitive information like login credentials, financial transaction records, authentication data, user preferences, and other information on the local device storage so the banking app would load the information faster. If not properly encrypted, fraudsters can gain access to this sensitive information and to user accounts that usually results in financial loss. 

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 legitimate app configuration allows a hidden invisible layer to be placed on top of the user interface. 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. 

That’s all about the treads. As you might notice, some user- and developer-responsible treads are interconnected. For example, if a user used unsecured public wi-fi to authorize into the banking system and fraudsters intercepted the data transfer with the user’s credentials, the stolen data would be useless if properly secured.

Now, it’s time to speak about ways to address all these security issue. The next secion will explain 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: 

1. 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. 
2. Recommended measures – some non-obligatory, but highly useful measures. 
3. 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 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.
• Unintentional data exposure: Multifactor authentication prevents 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.
• Fake or rogue banking apps: The same as previous: even compromised credentials don’t give access to the personal account.

Must #2. Secure Data Transmission

This measure involves encrypting data as it moves between the mobile banking app and the bank’s servers. Typical methods are use of secure protocols like TLS (Transport Layer Security),  use of tokens (like OAuth or JWT), and integrity checks such as HMAC (Hash-Based-Message Authentication Code) to verify the data wasn’t altered during the transmission. 

Threats it addresses:

• Using unsecured Wi-Fi networks. Ciphered intercepted data is almost always useless for any fraud. 
• Man-in-the-middle attacks. Prevents attackers from eavesdropping or tampering with data during transmission.

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 ciphertext is useless without a corresponding secret key that turns it back into an original, readable format. 

One of the most robust encryption algorithms we leverage is the Advanced Encryption Standard (AES), which has a key size of at least 256 bits. 

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

Secure coding practices imply a set of activities during coding that aim to mitigate potential security vulnerabilities. These include 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. Protection from known vulnerabilities makes the application more resistant to trojans and malware. 

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 document or described process of handling situation with data breaches, cyberattacs, or any other incidents that refer to cybersecurity. The plan covers several sections devoted to different routines or procedures for identifying, containing, mitigating the issue, and notifying the users about the issue. 

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: 

Identification – a bank discovers unauthorized access to its customer database. 

Containment – the response team identifies the affected systems and databases and isolate them to prevent further damage. 

Eradicatoin –  the response team identifies the breach source. In this case, it was an unauthorized access from the remote developer computer that was compromised. They stop the active session from the developer’s computer, remove the access, and run the file check to identify new suspicious files or code changes.

Recovery – any changed files are recovered from backups, password are changed. 

Lesson learned – the incident is thoroughly reviewed. That results in enhancing the security of remote developer access, improving monitoring and detection systems, aonducting additional security training for staff. Additionally, the bank reached its customers to notify them about the data breach. 

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 several practices: 

• First of all, it’s secure cookies that HttpOnly and prevents access via client-side scripts. The use of the SameSite attribute can prevent cross-site request forgery attacks. 
• Secondly, it’s sessiont timeouts to automatically log users out after a period of inactivity. 
• Store session server-side in secure and encrypted databases. 
• Use JWT (JSON Web Tokens) for session management. 
• Monitor and log sessions. 
• One user = one session.

Threats it addresses:

• Device loss or theft: session timeouts mean that the user will be logged out of all systems, making it impossible for fraudsters to continue the previous unclosed session. 
• Rooting and jailbreaking devices: server-side session management ensures the risks from malware and unauthorized apps are minimized. 
• App-based vulnerabilities: secure cookies and session tokens protect against certain types of XSS and CSRF attacks that exploit session vulnerabilities. 
• Insecure data storage: server-side session management is secure by default. 

Recommended #2. Patch Management and Dependency Updates

Robust security requires regular security updates. There are several great tools we use for that: OWASP Dependency-Check, Snyk, and GitHub’s Dependabot. They automatically scan the project’s dependencies for known vulnerabilities and suggest updates. Moreover, there are multiple handy websites that monitor the latest vulnerabilities and publish patches to them. The most reputable are: 

• Common Vulnerabilities and Exposures (CVE);
• National Vulnerability Database (NVD);
• OWASP Top 10.

Threats it addresses:

• App-based vulnerabilities. Regular patching and updates close known vulnerabilities in the app and its dependencies.
• Mobile malware and trojans. Updated applications are less vulnerable to exploits and malware designed to take advantage of outdated software vulnerabilities.

Recommended #3. Handling Errors Without Exposing Sensitive Information

Revealing additional information to the client-side regarding any errors could aid attackers. A secure way of handling errors is to provide as little information to the Client as possible and log the detailed errors server-side where they will be reviewed by authorized persons later. 

One more practice I recommend is to use a global error handler that catches error exceptions and handles them. 

Here are some common errors and examples of how to handle them: 

Threats it addresses:

• Phishing and smishing. Hidden detailed error information prevents attackers from crafting more convincing phishing or smishing attacks.
• Unintentional data exposure. Decrease the value of screen sharing with unauthorized parties. 
• Insecure data storage. Reduces the risk of exposing details about data storage mechanisms.  
• App-based vulnerabilities. Concealing the specifics of errors prevents attackers from gaining insights into potential vulnerabilities or misconfigurations they could exploit.

Mobile malware and trojans. Prevents malware from receiving detailed information about the app’s inner workings through error messages.

What About Users? Measures to Address User-Responsible Threats

Two basic principles work here: inform users and use secure configuration as default. Here is our security checklist to address user-responsible threats when we deal with mobile banking security: 

• Educate users on the importance of security practices and how to recognize potential threats. They must be proactive participants in guarding themselves. 
• Setting the application to operate with the highest security settings by default.
• Incorporating multiple verification methods, such as biometrics or one-time passwords.
• Develop and promote a single encrypted communication channel within the app.
• Continuous monitoring of user activities and automated logging help in the early detection of suspicious behaviors indicative of security breaches.
• Implement timely alerts about the latest phishing schemes and evolving tactics used by cybercriminals.

Encourage uses to use features like remote device wiping and location tracking to protect their data in case their mobile device is lost or stolen.

How Do I Know All This? I Implement These Measures In SumatoSoft

SumatoSoft is a reliable outsourcing software development company that became a technical partner to many businesses. We build software for multiple industries: eCommerce software, Elearning development, Financial software development, healthcare software development, Real Estate, Logistics software, Banking IoT development, Travel, and more. We implement all measures from the article when dealing with mobile banking security.

Facts about SumatoSoft: 

• We strive for quality and security and ISO 27001 and ISO 9001 certificates can prove it. 
• We focus on long-term cooperation. 70% of our Clients come back to us with another project. 

• Our Client’s satisfaction rate is 98%, thanks to our firm commitment to deadlines and their needs. 
• Your project data stays safe. We guarantee the security of all data related to your project
• We only release the software if it meets the specified percentage of acceptance criteria. The percentage is agreed upon with you in the quality assurance strategy. 
• 70% of our team is senior-level developers and QA engineers who ensure the app complies with domain best practices and our inner quality assurance guidelines. 

When looking for a strategic IT-partner for the development of a corporate ERP solution, we chose SumatoSoft. The company proved itself a reliable provider of IT services.

We are pleased to mention that the work Is done to the full extent, on time and on a high quality level. It complies with the requirements due to the highly skilled project team of our chosen partner.

The work is fulfilled with due regard for the peculiarities of the project, namely:

• Domain complexity of the business solution;
• Raised standards for the implementation rate;
• Early consideration of the system’s scope and complexity when developing the solution’s architecture.

We recommend SumatoSoft as a reliable partner in the sphere of development and implementation of complex business solutions.

Yuriy Semenchuk

General Director, Business Car

View case study

View case study

Get in touch with us for a free consultation. Let’s build a new product together!

Afterwards

So, mobile banking security is an achievable goal. It indeed requires the usage of multiple methods and techniques, but the final result is worth it. 

The importance of technical security is out of the question, however, I want to highlight the users’ role: they must be actively engaged in protecting themselves. Even the most modern security methods, technologies, and techniques couldn’t protect a user with a rooted device who installs applications from dubious unofficial sources, doesn’t set a password for device lock, ignores two-step authentication methods, uses public wi-fi for transferring sensitive data, and isn’t aware of fraud schemes. 

Robust mobile banking security is a collaborative effort of users and developers rather than a huge number of used security techniques. 

Thank you for reading.