PSD2: Is the banking industry prepared?
This article was first published in the June 2018 issue of Computer Fraud & Security.
January 2018 introduced significant change for both the banking and cybersecurity industries due to the introduction of the EU’s updated Payment Service Directive (PSD). The mandate, known as the PSD2, enables all bank customers, both consumers and businesses, to use third-party providers to manage their finances. Despite mobile operating systems actively discouraging the linking of applications, in order to ensure data protection banks are now obligated to provide application programme interfaces (APIs) to allow third-party providers access to their customers’ accounts.
The only way the PSD2 will function effectively and securely will be through the mobile banking application itself. However, it does not specify how this is going to work. We must question how secure this access will be, as well as what risks will arise, and for whom. After reviewing the PSD in 2012, the European Commission found that the legislation had introduced a number of benefits. As it is vital that legislation remains relevant to the environment to which it relates, six years on, it’s probably time for an update to the terms laid out previously.
“The revised PSD2 is aimed at providing more flexible banking for users, meaning customers will be able to mix and match individual solutions as they see fit”
The original PSD needed to be updated in order to accommodate for the changes occurring within the financial services industry and the payment sector. This includes incorporating technological innovation as well as further clarifications, improvements and protection. The revised PSD2 is aimed at providing more flexible banking for users, meaning customers will be able to mix and match individual solutions as they see fit, without having to transfer money from their original accounts to create new ones. Non-banking solutions such as paying bills or transferring money via social media will also be included in this.
APIs – a summary
One of the central mechanisms for PSD2 to work is the use of APIs. Essentially, an API is a set of instructions or routines to complete a specific task, or interact with another system, from servers to other applications. APIs are able to perform tasks such as retrieving data or initiating other processes so developers can integrate different APIs into their software to complete complex tasks.
APIs have become a key aspect of software development. Rather than spending innumerable hours writing every facet of the software from scratch, developers can pick from an increasingly large selection of best-of-breed APIs developed by specialists and plug them straight in. Using ready-made components allows developers to considerably reduce costs and time-to-market. Furthermore, developers are provided with more time and resources to contribute to the innovative and unique features that will make their application stand out from the rest.
Unfortunately, as with most things, APIs do have flaws. A particular weakness is the simple authentication that is widely used by most API management solutions to confirm that the client app on a device is genuine and has been authorised to utilise server assets. Typically, this is done using a simple challenge-response exchange, as the client application tries to connect to the API server. This exchange is usually a cryptographic operation, which means that the mobile client generally contains a secret key for an asymmetric cipher such as RSA or ECC. If attackers are able to break the application’s security and decompile its code, they can root out the encryption keys.
“An API that accesses data on the back-end server for a cloud application could provide attackers with the ability to break in and steal sensitive data or perform other malicious activity”
Any application that is available for download is particularly vulnerable as hackers are able to isolate it in a sandbox environment and attack repeatedly until they find a way through its security. Once an app has been cracked and the APIs have been accessed, they can use them to trick the system into recognising them as a legitimate client and enabling them to access anything the API was authorised to connect with. An API that accesses data on the back-end server for a cloud application, for example, could provide attackers with the ability to break in and steal sensitive data or perform other malicious activity. To prevent tampering, keys need to be defended with code-hardening measures such as obfuscation, a process that renders code into unusable scramble, or debugger detection, which will sense if the application has been booted in a debugging environment used by hackers.
While some banks already have a way of publishing APIs, others do not, meaning there is inconsistency across the industry. With the ones that do, again there is an irregularity as there is no standard. This means one bank can publish a certain set of APIs that have been mandated in a particular way, while another bank can publish a completely different set of APIs. Consequently, the way each bank communicates and authenticates customer data is different.
“The only way the banks can ensure that the data is safe is to bring the technology and countermeasures that they already have in their mobile apps and basically force an authorisation through the app”
With this inconsistency come the practical problems of consuming these APIs. Depending on which bank the customer’s account is with, the third-party app being used to access that same account would potentially have to build a different adapter, essentially a different API to access the data. This disconnected approach makes things more complicated for both app developers and their end users.
As the PSD2 is only going to function effectively through mobile banking applications, there must be perfect integration, authentication and communication between the banking and third-party applications sharing customer and transaction data.
Mobile phone systems themselves prefer to keep individual applications separate and therefore actively discourage secure communication between applications, resulting in better protection of the end user’s privacy. However, this can cause all sorts of issues when it comes to the necessary connection between the banking and third-party applications. The point at which the two applications will connect is also the most vulnerable point, the one at which attackers can intercept data going from one to the other, or even plant malware.
Keeping mobile apps separate hinders the guarantee of secure integration, authentication and communication between the two applications. Essentially, there remains a gap that can easily be exploited. In a perfect world, there would be completely secure communication between the applications, meaning at no point would either of them be manipulated, nor data leaked. However, this is no simple task. If attackers are able to intercept the communication, they can use a malicious application to hijack the original third party app, meaning that once the user allows the third party app access to his banking information, the malicious app gains access too.
Risks for banks
Banks spend a colossal amount of money on security because their reputation depends on it. However, while banks are big on security, third-party applications are not under the same scrutiny and their ‘mindset’ does not consider security as much of a priority. On the surface this makes sense, as banks require a larger amount of personal information from their customers, much more than most third-party apps will. Due to this, the majority of third-party applications will not be subject to the same regulations as banking applications, particularly with regard to where data is stored and who can access it. However, if the banking applications are going to be obligated to provide APIs to third-party applications, they will have to adopt the same standard of security.
The PSD2 is quite clear that banks will be responsible for the ownership and safety of customer data and, moreover, the confidentiality of it. The only way the banks can ensure that the data is safe is to bring the technology and countermeasures that they already have in their mobile apps and basically force an authorisation through the app. This will give them direct communication with the end user at the point before the third party has even been given access to the data.
Another matter that needs to be addressed is when a third-party app calls to the bank to access the customer’s account data. The principal issue here is how the bank is to know that when Facebook, or another third-party app, is calling, that it is in fact acting on the user’s behalf and that the user has given it permission to request access. Most banks require two-factor authentication (2FA), and PSD2 likewise mandates 2FA for making payments. The way most banks will implement 2FA is through their banking application, using certification, biometrics (including fingerprints) or behavioural biometrics to identify the user.
Incorporating 2FA with the PSD2 rules is easy enough if it is all done on a mobile. However, if not, there are certain challenges to overcome. If you’re using a third-party app on a desktop version of the application but want authentication from the bank, you will require some sort of handoff to the mobile app, which will then be able to securely authenticate the user. Facebook is then given explicit permission for limited access to the user’s data.
“An important question is whether the third-party app provider will be able to access that data at any time, even if the user is not logged into the app or using it at the time”
The banking industry, while sticking to the PSD2 guidelines, will need to find a way of ensuring secure data access and permission management, while also preventing the manipulation of the apps. One way to do this would be to provide screens, or a way of managing permissions to monitor how long third-party applications will have access to customer data, as well as confirming that the customer is happy for the third-party applications to still have access. The banks have the ability to allow users to set preferences on the application but there’s no saying that they will be able to control, or have a say in, permission preferences on the third-party application.
Despite seeming to have improved their authentication methods, it is still possible for someone to compromise a third-party’s server and steal personal information. Therefore, the security of the applications does not just rely on a case of authentication in the apps but also the greater lifecycle of the data.
The lifecycle of data held by an application is essentially how long the app – again using the example of Facebook – will have access to that data. An important question is whether the third-party app provider will be able to access that data at any time, even if the user is not logged into the app or using it at the time.
If the data is accessible, this would suggest that banks will have to provide a way for customers to be able to manage when and what data is accessed and provide insight into issues such as who’s got access to that account, when they last accessed that account and what data they accessed. Furthermore, they will have to enable the customers to block such access if they so wish.
Overall, PSD2 will create security concerns among the banking industry and its customers along with the new opportunities it sets out. However, there is a variety of security solutions such as code hardening techniques that will help the banks to keep customer data safe, while still providing users with the freedom and flexibility of accessing their bank account through other mobile applications.
Nevertheless, it is vital that the banking industry is armed with a strong strategy for whatever solutions they will be implementing for themselves and third parties in order to be fully prepared for the ramifications of the PSD2 mandate.