Security Features in Financial Applications – our recommendations

Background

Over the past several years Securing was the substantive partner in the assessment of the current state of banking applications in all major consumer banks in Poland. What made this assessment different and worth mentioning is the fact that it was not a typical penetration testing. 

Our team compared numerous banks (both web and mobile applications) in terms of presence of security features, like 2FA or limits management. The technical quality of those features and its implementation was not in scope. 

During this general review, we came to a very important conclusion – not only technical quality of security features matters, but also – perhaps even more importantly – its presence.

“In some cases testing team may assume that some vulnerabilities or lack of security feature is a business decision”

Typical penetration testing assessment lets you identify on technical ground if “limits management” is implemented properly. Testing team should find a vulnerability that allows one user to modify the limits of the other one. Great, but penetration testing would not report that limits management is not granular, in case that you can only set one, global limit for all the payment methods. Testing team would assume that it was just a business decision. This is also the reason why threat modelling should always be done at the application design phase.

Introduction

In this article I am going to present to you “Financial Applications Features – Security Guidelines” (FAFSG), which is a ASVS-like checklist of security features which you can implement to make your app more secure. Just keep in mind that FAFSG is not a technical standard and it does not cover implementation guidelines and quality of proposed features. For such guidelines, please refer to OWASP ASVS for web applications and OWASP MASVS for mobile applications.

You can go straight to our project on GitHub HERE or download the checklist below: 

Also, I will present some of the results of our comparative studies on security features present in Polish banking applications. The results will be grouped by categories and platforms (mobile/web). I am hoping that the presented insights will start a reflection of the current state of banking applications in your area and perhaps will result in several ideas which may increase the security level of those applications.  

Security Features in Banking Web applications

Authentication

According to the PSD2 directive introduced by the EU commission in september 2019, each financial application should use SCA to authenticate users, at least once in 90 days. Our study shows that there are several approaches and interpretations of these requirements. 

• 42% of banks simply use SCA once in 90 days and do not allow the users to configure this behaviour. 
• 14% of banks took a completely different approach and simply asked for additional authorization on each login. 
• 42% of banks implemented a “Trusted Browser”, which allows users to authorize the current browser and later on login from this particular browser does not require SCA, while it is enforced on different browsers and devices. 

Another worth-mentioning observation is the fact that 21% of banks offer only masked passwords as an authentication method, which is not a good practice. 

Transaction Authorization

All of the banks which we had the opportunity to test allow its clients to authorize transactions with SMS code, and the vast majority of them allow (and oftenly promote) PUSH notifications as an alternative. Only one bank still permits the usage of physical cards with authorization codes.  The latter method is not considered secure, because such a physical card can be easily lost or stolen.

Our tests also showed that one bank did not enforce transaction authorization in each case of external transfer to an untrusted account. We managed to establish that the bank utilizes a proprietary algorithm which categorizes transactions and in case of transfer for low amount and to accounts marked as secure by bank, authorization is not needed. 

Last but not least, only 28% of banks have authorization history accessible in the application interface. 

Limits and Notifications

Limits and notifications management are very important, yet often underestimated features of modern financial applications. Granular management of limits allows the user to tailor an application to their needs and simultaneously reduce financial impact of potential security incident. 

Notifications on the other hand, are a neat tool which allows for quick incident response, if configured properly. Again, in this case the user should be able to tailor this mechanism to their needs.  

Security Features in Mobile Banking applications

Authentication

Similarly to web applications, mobile applications also must be compliant with PSD2 directive.
All of the tested applications implemented mobile application pairing mechanisms, which is an initial and mandatory step for the users. During this process, an unique application identifier is generated and stored in the device. This identification combined with a user PIN / biometry can be considered as SCA. our studies confirmed that 64% of applications does not enforce strong PIN codes: 

Authorization

Transaction authorization in a financial mobile applications is a bit tricky. In the case of web applications, the second channel used for authorization is based on the access to mobile device (SMS or PUSH). Having that said, suppose that a malicious transaction originates from a mobile device – in such a case we need to assume that the mobile device is compromised and we cannot rely on the authorization. So, what can be done? 

In the perfect scenario, there should be a dedicated PIN for authorization, which is different from the PIN used to authenticate. Also an acceptable solution is to use biometric for authentication, and PIN for authorization (or other way round). The two solutions which cannot be considered secure are using the same PIN for both operations, or – even worse – rely on PUSH or SMS code as a transaction authorization on mobile devices. 

Limits and Notifications

More and more often mobile applications are preferred by the banks clients over web applications. Following that line of thought, it is a simple conclusion that mobile applications should offer at least the same set of functionalities as its web counterpart. Unfortunately, banks still does offer significantly less features in terms of limits and notification management in mobile applications:

Mobile platform related security features

Financial mobile applications should implement a set of platform specific features, which are thoroughly described in chapter V8 of MASVS (Resiliency requirements). 

It turns out that certificate pinning is implemented in nearly all the applications, while 64% of mobile apps detect root or jailbreak:

Additionally, source code obfuscation is implemented in only 50% of applications and the following features were implemented in 64% of applications:

• Dedicated keyboard, 
• Vendor verification,
• Snapshots protection.

Financial Applications Features – Security Guidelines

Based on our experience with penetration testing of financial applications and with knowledge gained during an assessment of web and mobile banking applications, I decided to start a new project: the “Financial Applications Features – Security Guidelines” (FAFSG), which is a set of two FREE checklists created to standardize and aggregate the security features that have a real impact on security of financial applications. 

The goal of this project is to help to make security decisions for developers, architects, reviewers and vendors in order to implement essential security features in financial applications. Those features would help to protect users data and increase overall security of the application. 

Keep in mind that FAFSG is not a detailed, technical standard and it does not cover implementation guidelines and quality of proposed features. For such guidelines, please refer to OWASP ASVS for web applications and OWASP MASVS for mobile applications or check out our presentations on this subject.

We are open to accept any contribution and I will be more than happy to see any suggestions to this project. If you want to improve the project in any way – please contact me on Linkedin or Twitter.

Summary

Security features and application design has a critical impact on application security, however I feel that those aspects are overlooked by the IT security community. 

We are mostly focusing on technical aspects of the applications, finding vulnerabilities is always thrilling and exciting, but sometimes a broader perspective is required and we should put more emphasis on application design and set of available features. 

This is why FAFSG was created and we sincerely hope that, together with your contributions, it will prove to be a helpful tool in creating financial applications.

Łukasz Bobrek Principal IT Security Consultant
Head of Cloud Security