Blog article
See all stories ยป

Don't worry about PSD2, your APIs are open anyway

PSD2, the European regulations for Open Banking, is designed to allow a more open and competitive Financial Services sector across the EU. There are pages and pages of information on managing the market, allowing companies large and small to compete, and the Security / Strong Authentication required to allow 3rd parties open access to banking APIs.

The thing is, these APIs have been effectively in the open for years. 

Mobile Apps and other software have been communicating via APIs for some years now. Major enterprises across multiple markets have found the principle of the API to be useful in creating new networks and new value with the APIs being the conduits (and the glue) that brings them together. Many enterprises have freed their developers' creativity and the product teams have been able to diversify and thrive as rarely before.

This same advantage has been seized upon by Fintechs and established players alike.

How does your mobile Banking App communicate to the Banks' servers? How do you on-board to a new Mobile Financial service, such as Travel Insurance or a Savings product? How do Mobile Payment solutions ensure that they are connecting to the correct Card Schemes?

APIs.

Lets look at the last of these 3 examples; Mobile Payments. This is something about which Inside Secure can talk authoritatively as we've been working in this space with the card schemes now for 5 years and the principles, process and architectures are both well established and are also now pretty much standardised.

The Card Schemes (generally) have been standing up their Token Services, the means by which your credit card number is converted to an apparently random number and is used to allow contactless payments. Among the drivers for these services have also been the OEM Pays and both they and the Banks' own Payment Services connect to the Token Services via APIs. Of course Payment generally is a very well regulated market, that is PCI and EMVCo, as well as the card schemes realise that any loss of trust in a system is extraordinarily difficult to regain and there for security is paramount.

The same, unfortunately, cannot be said for other Mobile Financial Applications.

The problem is simple, Mobile Devices are not network device, they aren't even analogous to laptops. They have many more input and output requirements and a Mobile App is afar more sophisticated piece of software than simply opening a browser window. All the information needed to connect to a Bank's servers, via the Banks' carefully crafted APIs are contained within the application.

To some degree this is recognised, as we found in our first research into the Wild West of Mobile Banking in 2017, there are a number of features that some of the App Developers used that demonstrates their awareness of the challenge - the inclusion of SSL or CertPinning in an attempt to ensure the app connects security to the correct server are examples. 

However, while these are useful tools, what they don't do is to prevent an attacker analysing the application in order to reverse-engineer access to the API to which the app connects, worse still it also gives the attacker the correct SSL and Certificates to utilise in a later attack on the Bank's systems.

We've seen examples of this in the wild, one of our largest Banking customers (a US household name) tells us they see multiple attacks on their Mobile Apps every day.

A more benign example is a small UK company who pre-empted the PSD2 requirements for Open APIs by several years. They (correctly in my opinion) determined that offering a mobile App that consolidated a consumer's entire Financial life into one aggregated application would be attractive to many.

Indeed HSBC has just successfully launched something similar - under PSD2. 

But, as this UK Start-up was 4 years ahead of the ECB's requirements they had no way to access the banks' APIs in order to pull all the account data together for their customers. Their business was stalled, until they realised that the API data was generally sitting, unprotected within each an every Banking App that is sitting on the Google PlayStore, all they needed to do was analyse the Apps at a source code level. So they did, they can now access the Banks' data with impunity.

Of course, this latter example was a small company using ingenuity to offer a new service, well ahead of the industry, but those same techniques are equally useful to less scrupulous hackers who see Financial Services as the next big pay day (as the Credit Card market becomes ever more difficult).

The answer is very simple -  follow the model of our US Banking Customer and stop the analysis (and compromise) of Financial Services apps in the first place.

 

a member-uploaded image

Comments: (2)

Ambrish Parmar
Ambrish Parmar - Independent Contributor - London 08 August, 2018, 10:38Be the first to give this comment the thumbs up 0 likes

Hi Douglas, thank you for posting and welcome to the group.

Great article; I would be intetrested in your view of how best to govern open API eco-systems. Many thanks, Ambrish

Douglas Kinloch
Douglas Kinloch - Inside Secure - Glasgow 13 August, 2018, 14:27Be the first to give this comment the thumbs up 0 likes

Hi Ambrish, It's a combination of factors. The "end-point accessing the APIs themsleves has to be scured, thus ensuring that the prblem I dicuss is not possible.

The Comms within the endpoints too need to be secure, so not allowing SSL interceotion for a man-in-the-midle attacks and the MultiFactor authenitcation solution (demanded by PSD2) in itself needs to be secure.

There is no point in authenticating by fingerprint on an Android phone if that scanned fingerprint data can be spoofed or sniffed because the scanner is not secure.

Of courtse my definiton of the end poiunt iusn't th edevice (no device can be trusted) it's th esource code created by the developer of the device accessing the API. 

Douglas Kinloch

Douglas Kinloch

VP Financial Markets

Inside Secure

Member since

19 Jun

Location

Glasgow

Blog posts

4

Comments

2

This post is from a series of posts in the group:

Banking Strategy, Digital and Transformation

Latest thinking in respect to Banking Strategy, Digital and Transformation. Harnessing our collective wisdom to make banking better. Ambrish Parmar


See all