Obligatory and Optional Methods to Address Threats in Mobile Banking Security
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.
Learning from the best is always a good practice.
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:
A bank discovers unauthorized access to its customer database. The incident response team is activated, identifying the breach source and containing it by isolating affected systems.
They then eradicate the breach by patching the exploited vulnerability, recover by restoring the database from backups, and implement additional monitoring to prevent a recurrence. A post-incident review leads to improved security measures and response protocols.
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.
Threats it addresses:
- App-based vulnerabilities. Regular patching and updates close known vulnerabilities in the app and its dependencies, reducing the attack surface available to cybercriminals.
- 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 regarding any errors could aid attackers. To handle errors without exposing additional information, it’s necessary to avoid sending detailed error messages directly to the Client or user interface. Instead, log the detailed errors server-side where they can be reviewed by authorized personnel, and send generic error messages to the Client.
Additionally, we implement a global error handler in your application that catches unhandled exceptions, ensuring that no stack traces or system information is leaked. This approach minimizes the information that attackers can gather about your application.
Here are some common errors and examples of how to handle them:
Error | Handling | Example response |
Validation Errors (e.g., input validation fails) | Return a generic “Invalid input” message without specifying which input or rule failed. Log the specifics server-side for debugging. | 400 Bad Request with the message “Invalid input provided.” |
Authentication Errors (e.g., incorrect login details) | Avoid specifying whether the username or password was incorrect. Instead, use a generic error message. | 401 Unauthorized with the message “Invalid credentials.“ |
Authorization Errors (e.g., accessing restricted resources) | Do not reveal whether the resource exists or specifics about why access was denied. | 403 Forbidden with the message “You do not have permission to access this resource.” |
Server Errors (e.g., database is down, unhandled exceptions) | Log the error details server-side and provide a generic error message to the user interface. | 500 Internal Server Error with the message “An unexpected error occurred.“ |
This practice isn’t really user-friendly since developers deprive users of the information that could help them handle the error. It’s necessary to use other methods which are, unfortunately, outside of this article’s topic.Â
Threats it addresses:
- Phishing and smishing. By not exposing detailed error information, phishing campaigns have less information to mimic or exploit in social engineering attacks.
- App-based vulnerabilities. Concealing the specifics of errors prevents attackers from gaining insights into potential vulnerabilities or misconfigurations they could exploit.
What About Users? Measures to Address User-Responsible Threats
Two basic principles work here: inform users and high security by default. Here are the measures we implemented in the development to achieve mobile banking security with the threats that are out of our control:
- Educating users on the importance of security practices and how to recognize potential threats helps them become proactive participants in safeguarding their financial information.
- Setting the application to operate with the highest security settings by default minimizes the risk of user oversight leading to vulnerabilities.
- Incorporating multiple verification methods, such as biometrics or one-time passwords, adds an extra layer of security, making unauthorized access more difficult.
- Promoting the use of encrypted communication within the app protects user data from being intercepted during transmission.
- Continuous monitoring of user activities and automated logging help in the early detection of suspicious behaviors indicative of security breaches.
- Implementing timely alerts about the latest phishing schemes educates users on the evolving tactics used by cybercriminals, enhancing their ability to avoid scams.
- Features like remote device wiping and location tracking empower users 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.
Get in touch with us for a free consultation. Let’s build a new product together!
Afterwards
Ensuring mobile banking security requires a multi-faceted approach, integrating essential security protocols, developer best practices, and user education.
This article has highlighted critical security measures, including strong authentication, data encryption, and secure coding practices, alongside strategies for addressing user-responsible threats through education and enhanced security features. Adopting these measures will significantly mitigate risks and protect against evolving cyber threats, ensuring the safety and integrity of mobile banking applications.
Let’s start
If you have any questions, email us info@sumatosoft.com