By Feike Hacquebord, Robert McArdle, Fernando Mercês, and David Sancho
As more industries adapt to cater to the increasingly mobile market, the financial industry is the latest to experience a shake-up. The Revised Payment Service Directive (PSD2) – also known as Open Banking – is a new set of rules for the European Union (EU) that’s expected to affect the global financial industry. The PSD2, implemented on September 14, 2019, was designed to replace the 2007 Payment Service Directive in the EU, but banks in the US and Asia have started making comparable adjustments to accommodate their customers as well.
Open Banking aims to inspire innovation and make banking transactions in the EU more cost-efficient, easier, and more secure. This entails banks opening their application programming interfaces (API) to financial technology (FinTech) companies to accommodate additional services such as financial recommendations and payment automation. Bank customers will have to give their explicit consent to these new companies to access their respective banking data.
Figure 1. With PSD2, new FinTech companies will launch new apps to aggregate banking data from multiple accounts.
PSD2 aims to make online banking more secure. To this end, PSD2 mandates two-factor authentication and “Dynamic Linking,” wherein an authentication code for each transaction is specific to the amount and the recipient. Additionally, banks in the UK are developing a standard called Financial grade API (FAPI), an extra layer of security in the authentication processes between new FinTech companies and banks.
This research paper looks into the PSD2-readiness of FinTech companies and banks from a security perspective and the new risks that could emerge when PSD2 comes into effect. Open Banking places customers’ banking information into the hands of more parties, including new FinTech start-ups that may not have the same experience that the traditional banking industry has accumulated through years of addressing fraud. This inevitably implies that an increased attack surface. We found a few issues:
- Publicly accessible APIs of banks and FinTech companies will widen the attack surface.
- Some (legacy) APIs and websites of banks and FinTech companies had sensitive customer information in their URLs. This is not in line with the intention of PSD2 to improve security of online banking.
- Obsolete banking data sharing techniques are still in use.
- Some mobile apps of banks and FinTech companies also connect to third parties like advertisers and app performance service companies.
- More secure protocols, such as Financial grade API (FAPI), are still in development.
API status quo and risks
While European banks were considerably late in working with APIs in 2015, an increasing amount of banks worldwide uses APIs for data sharing.
Figure 2. Growth trend of a particular subset of financial sector API hostnames, taken from Trend Micro’s Smart Protection Network (SPN)
Before PSD2 went into effect, we found security issues in the APIs used by a number of FinTech companies and banks. A significant number of banks – including at least two central banks in Europe and one central bank in Asia – were unintendedly exposing sensitive information such as authentication parameters, privacy-sensitive data, and transaction data in the URLs of APIs and (legacy) websites.
Figure 3. APIs exposing users’ sensitive information
Putting sensitive data in URLs is a bad practice, as these URLs might end up in log files, the browser history, and might even be shared between different devices of a user. Our research paper enumerates a small sample size of financial institutions from Europe, Asia, and the US exposing confidential information (the list has been anonymized to protect their respective customers).
We also found a European FinTech company that published its API documentation online, including authentication URLs that included the customer’s email address, password, client authentication, and client ID in the API URL.
Figure 4. A screenshot of the online documentation of a FinTech company’s API, claiming to be regulated by PSD2. Sensitive information can be clearly seen in the API URL path.
Risky techniques: screen scraping
A technique called “screen scraping” is among the techniques used by FinTech companies to aggregate bank data. This involves parsing through the HTML contents of a banking website by mimicking a web browser session using the customer’s login credentials. For this to work, the customer has to give his online banking password to the FinTech company, which is not advisable from a security point of view.
As PSD2 mandates that strict authentication is required, screen scraping should no longer be allowed and has to be replaced by OAuth2.0. FinTech companies organized to push back against this stipulation, saying that no known incidents or breaches related to the technique have occurred, and cite that OAuth is not user-friendly. A few weeks before the mandated September 14 implementation, authorities announced a postponement in the full implementation of the technical security measures and fines in order to give third-party providers more time.
Financial grade API (FAPI) is a protocol intended to be secure even in high-risk scenarios. For example, if an attacker steals a mobile app user’s temporary access token, the attacker should not be able to use that token to access the victim’s financial data. FAPI is currently being developed by the OpenID Foundation and the U.K. Open Banking Implementation Entity. While intended for use once Open Banking takes effect in the U.K., it is not entirely ready; FAPI reportedly still has issues to resolve at the time of the research paper’s writing, including significant security flaws.
Predicting threats after PSD2 implementation
This new banking paradigm, which involves open APIs with access to banking data, brings new opportunities for attackers. Below are just some of the threats and possible attack surfaces
- Attacks on the APIs: Attacks on the APIs can result in distributed denial of service (DDoS), resulting in downtime for banking operations and transactions. A hacker can study how the API system works once it goes public and find unexpected responses and security flaws in the back end.
- Attacks on FinTech companies: Not all FinTech companies will have the same security level and experience that banks do. From a quick survey of these start-ups, they tend to be smaller and have no personnel dedicated to security, and can be subjected to an attacker pretending to be a legitimate bank or banking customer. Their servers can also be ideal targets to steal customers’ banking data.
- Attacks against the user: Old social engineering and phishing techniques will likely find traction against end users. Moreover, accountability and proving responsibility may become more complicated once a fraudulent transaction occurs.
Conclusion and security recommendations
While Open Banking promises better security and business opportunities for customers, banks and FinTech companies, the current implementations pose concerns from a security standpoint. The conflicting goals of FinTech companies eager to further innovation and services to the public, and banks trying to protect their established standing should not sacrifice the interests of the customers.
We recommend that FinTech companies embrace secure protocols and to stop using risky and outdated techniques. The lack of documented incidents are not equivalent to the fact that methods such as screen scraping are highly insecure. App developers should also make sure that their respective apps and websites are secure by design, and conceptualize applications that can run safely in a hostile and compromised environment.
Banks and other financial institutions should review their current apps’ APIs; sensitive information and personal data of customers should not be found on API URL paths as this could weaken or render established security measures useless.
For more risks and threats that we detailed and extensively discuss in the paper, download our research paper, “Ready or Not for PSD2: The Risks of Open Banking.”