It may have felt like a long time in the making but, on Saturday January 13, the Second Payment Services Directive (PSD2) officially came into effect. The directive is set to reinvent banking and payments as we know it, ushering in a new era of ‘open banking’, where customers have unprecedented freedom in how they access financial services. This new mandate aims to provide more flexibility and freedom to users, with customers essentially being able to mix and match individual solutions as they see fit.
As we progress through 2018, we hope to see banks clubbing together to establish mutual standards over how to implement PSD2 securely
As a result of this, banks are now required to share their application programming interfaces (APIs) with third-party applications. However, many have still not been advised on how to do this securely.
Weaknesses in sharing APIs
The principal weakness in sharing APIs 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. If a cyber-criminal breaks through an app’s security and decompiles its code, they could potentially root out the encryption keys. Attackers can then trick the system into recognising them as a legitimate client, giving them access to anything the API is authorised to connect with.
To prevent attackers from exploiting an API in this way, banks will need to ensure that the cryptographic keys they use to authenticate themselves cannot be accessed. This can be done through techniques such as code obfuscation, a process that renders code into unusable scrambled code; or debugger detection, which will detect whether the application has been used in a debugging environment used by hackers.
Can PSD2 function securely?
The only way we can be sure PSD2 will function effectively and securely is through the use of mobile banking. However, mobile phone systems tend to actively discourage secure communication between different applications so that the privacy of the end user is protected. This means that no application is able to see what other applications are on a mobile device because barriers have been put in place to avoid mobile phones working as interim solutions. Nevertheless, PSD2 wants to break these barriers. Therefore, it is vital there is perfect integration and authentication between the banking and third-party application’s customer data. Without this, user data, including account details and usernames, are at risk of exposure due to a lack in security.
Taking responsibility
The truth of the matter is that PSD2 is something everyone is going to have to deal with, and it is going to have a big impact on mobile application development. As we’ve said before, the onus really is going to be on the banks. The PSD2 regulation makes it clear that they are responsible for the ownership, safety and confidentiality of their customers’ account data.
The only way the banks can ensure the security of their customers’ data is by implementing the technology and counter measures that they should already have in place in their mobile applications. Basically, the best and most secure way to allow third parties to share their APIs is for the banks to force an authorisation through the mobile banking applications. This should then allow them to directly communicate with the end user before any third-party application has been permitted access to the data.
Furthermore, as we progress through 2018, we hope to see banks clubbing together to establish mutual standards over how to implement PSD2 securely. Such standards will involve: securing the API; securing authentication between the applications; and creating a mutual code of connection for anyone that wants to use it.
Overall, banks are going to have to do everything they can to maintain their well-founded reputation as leaders in security, including creating a united approach to ‘open banking’, as they work on their own solutions throughout 2018.
