Digital Transformation is in full swing in the banking sector, and it’s brought along a number of crucial advantages to financial institutions.
But mobile banking – possibly the most important innovation from users’ perspective – comes with a number of risks. In this article, we will look at why security is such a complex issue for banking, and we’ll analyse ten security flaws that no mobile banking app should have.
According to Business Insider’s US digital banking report, 89% of respondents use mobile banking to some extent, while 70% of them depend on it as the primary means of accessing their accounts.
Banks can benefit from this trend tremendously – provided that they define their strategies based on consumer behaviour. At the end of the second decade of the 21st century, people are used to always having their smartphones on them, and they want access to their money wherever they are.
The fear and distrust towards mobile banking has gone.
It’s time to leverage this change in attitude. Take a look at these two incentives to get you started:
The banking sector is unique in a number of ways. Stringent security regulations for banks mean that the development process needs to be adapted to fit their security strategies. Appropriate resources should be allocated to applying good security rules to apps, at the expense of longer development time. Particularly, banking apps should go through a rigorous quality assurance process, passing every kind of test, to protect users’ interests.
In many ways, fintech businesses – like Revolut – have it easier.
They are often mobile-first, offering the expected suite of mobile features, and bringing Digital Transformation into the sector, thus forcing financial institutions to adapt. Fintech innovators, therefore, have a number of advantages:
As such, banks often stand before a much more complex challenge when introducing their mobile solutions. However, they have the advantage of their established position and existing customer base when launching a new mobile product.
Why is it so important to provide the highest level of security in banking apps? To find the answer, let’s deconstruct the question first.
Data security is a complex issue due to three major aspects:
When one element fails, the others can’t always compensate. Even the most effective, well-implemented security tools won’t stop people from making mistakes.
The conclusion is bleak: your or your users’ data can never be fully secure. However, we can significantly reduce the likelihood that a mobile banking security breach will occur.
There is no universal scenario for a bank security breach, as much depends on what data is leaked. For the most part, however, the consequences are dire.
Customers, especially those who suffer direct losses, may issue complaints and seek compensation, further damaging the bank’s reputation and, if the event occurs on a larger scale, causing significant losses.
Here’s an example. N26 is a European mobile banking startup. What we’re going to describe are issues that have already been fixed – N26 took responsibility for the situation. Due to lax security rules below industry standards, N26 exposed their customers data and made it possible for third parties to:
Luckily, the security flaw responsible for this vulnerability was found before it could be exploited, according to N26’s statement.
To provide an unbiased view of an issue so critical to the industry, we focus on flaws listed in the OWASP mobile vulnerabilities report. OWASP (Open Web Application Security Project) is an open community that creates software security guidelines and makes them available to everyone.
iOS and Android offer their own unique security features, such as TouchID or permissions systems. Failing to use them can be a big mistake. Each platform offers guidelines for building secure applications, and sticking to them can help you avoid many threats.
The risk: Users’ sensitive data can be corrupted through improper implementation of platform features.
Every app uses data, and thus every app needs some data storage. For sensitive information, the storage solutions used need to be very secure (especially internal storage) – it’s the first step of successful data leak prevention.
The risk: Unprotected confidential data can be accessed and used for various illegal activities, such as stealing money from a victim’s accounts.
The strategy: Use proper, secure algorithms and and save sensitive data in internal storage with proper encryption.
Mobile applications communicate with external data sources, such as servers, bluetooth devices, NFC, etc. This communication cannot be avoided, as apps’ core functionality often depends on it. Without adequate protective measures, however, it can result in data leaks.
The risk: There are tools and techniques for externally accessing the communication traffic of a device – such a breach may lead to fraud or identity theft.
The strategy: All communication should be encrypted using SSL, along with other appropriate communication security tools like strong authentication or good encryption algorithms.
Modern apps, and banking apps in particular, provide users with many authentication methods, such as user ID and strong passwords, PINs, fingerprint scanning, etc. Strong authentication allows users to manage assets within the app securely.
The risk: Without proper security measures, authentication can be bypassed by malware, resulting in unauthorised access to sensitive data.
The strategy: As local authentication is more vulnerable, apps should include server-side authentication options, if possible. Additionally, no app should store the user’s password on the device.
Cryptography uses algorithms to transform raw data into strongly encrypted, secure packages. Encrypted data cannot be read as-is, and breaking the encryption usually requires too much time and processing power for any potential attacker to succeed. Stolen encrypted data is therefore useless to them. However, some algorithms are easier to break than others, and as such they shouldn’t be used.
The risk: Weak encryption or no cryptography-based security measures expose users’ sensitive data, which can then be used for further attacks.
The strategy: Use algorithms and standards that have been thoroughly tested and accepted by the community. It’s often best to avoid storing any data on a mobile device, making it only accessible from a server.
The difference between authentication (which we’ve already mentioned) and authorisation is subtle. Authentication is a method for detecting individuals, allowing the app to know who is logged in. Authorisation determines which parts of the application are accessible to a given user, based on their role (such as administrator or end user). Through well-architectured authorisation, you can make sure that each user will receive just the data they have been granted access to.
The risk: Insecure authorisation may allow users to access data that is restricted to another role. An attacker can exploit this vulnerability and gain access to sensitive information.
The strategy: Avoid relying on roles and permissions enforced on the mobile device. Instead, each role within the app should be based only on server data.
Measuring code quality is like inspecting each block in a Lego construction. The blocks include pattern usage, test coverage, consistent coding style, proper layering, etc. If you find that your app’s code is lacking in one of these areas, it should be a cause for concern. Poor code quality makes it very difficult to maintain an application over time. Any change in the code, such as a new feature, may introduce vulnerabilities.
The risk: Attackers can use code analysis tools to steal sensitive information.
The strategy: Use consistent coding patterns following mobile app security best practices. Additionally, keep documentation of your code to help new developers on the team understand and comply with those coding patterns.
It is possible to change some parts of your app’s binary code and create copies of them. This might allow an attacker to tamper with API calls and execute malicious code. Typically, attackers distribute a malicious version of an app through phishing attachments.
The risk: An attacker may intercept communication and steal data, or gain unauthorised access to parts of the app (e.g. stored user data).
The strategy: Technically, all mobile code is vulnerable to code tampering. Mobile code runs within an environment (a mobile platform) that is not under the control of the code’s creators. Therefore, every mobile app must be able to detect at runtime that its code has been tampered with (through additions or changes), based on what it knows about its integrity during compilation.
Reverse engineering is the process of accessing an app’s source code from a compiled file and studying it to learn the business logic of the application. It’s even possible to use reverse engineering to check what security tools have been implemented.
The risk: Reverse engineering may reveal backend authentication secrets. It is often the first step of an attack. Reverse engineering may give an attacker useful information on an application’s logic and security measures.
The strategy: Use code obfuscation tools, making it more difficult to determine logical connections between parts of your code.
Developers often create backdoors to access hidden functionalities, such as additional logs displays, or shortcuts to certain parts of the app. Though it makes development work easier, such hidden functionalities that are still present in a live app may expose sensitive data and should be avoided at any cost.
The risk: It depends on the hidden functionality. Examples include users accessing restricted features and data leaks.
The strategy: Perform a security exam for your app to make sure that all the unnecessary code has been removed from the production version.
USAA’s (United Services Automobile Association) app is one of the best mobile banking apps. It implements facial recognition through secure algorithms.
Its security features range from standard (fingerprint scanning) to very rare (voice recognition). All this to protect access to users’ bank accounts. Providing customers with this much security not only protects the company from complaints or lawsuits, but also builds trust and bolsters the image of an organisation that takes the safety of their customers seriously.
According to the McAfee Mobile Threat Report from 2018, the creation of malware is an extremely profitable endeavour, a prevalent banking Trojan could potentially bring in revenue of $1 million–$2 million.
It could create revenues for malware authors touching in the billion-dollar range by 2020. This type of criminal activity is becoming more widespread as people warm up to engaging with financial institutions online and through their mobile devices. Investing in effective security measures is now less a choice – it’s simply a necessity.
Remember that even small mobile banking security issues, without much impact on the business or users (e.g. leaked but encrypted and therefore inaccessible data), may tarnish the trust customers vest in your company.