Many of you, no doubt, have heard of the European Union’s European Banking Authority (or EBA) directive called PSD2 (short for Payment Services Directive). These guidelines were originally published at the end of 2015. By January 2018, all member states were required to implement the regulations.Key purposes of PSD2 include
- To open new market opportunities for a variety of players such as online merchants, while leveling the playing field for all key stakeholders
- To provide consumer transparency and consumer choice
- To introduce new and more robust security practices for online payments
There are a number of guidelines in general for PSD2; however, one of the better PSD2 Guidelines can be downloaded from MEF (Mobile Ecosystem Forum).
Strong Customer Authentication
One of the key elements of PSD2 regulations is the concept of Strong Customer Authentication (or SCA). The EBA notes: “Thanks to PSD2 consumers will be better protected when they make electronic payments or transactions (such as using their online banking or buying online). The Regulatory Technical Standard (RTS) makes strong customer authentication (SCA) the basis for accessing one's payment account, as well as for making payments online.” In short SCA calls for, at minimum, two-factor authentication (2FA).
Two-factor authentication means that users will have to “prove” their identity by two separate elements of three:
- Something they know (a PIN code or password)
- Something they possess (a mobile device, a card)
- Something they are (fingerprints, face scan: e.g. biometrics)
The EBA notes that SCA is commonly used throughout the EU; however, this is not always the case for online payment transactions such as a credit card payment or direct bank transfer. SCA is applied in the EU countries of Belgium, the Netherlands, and Sweden); however, in other EU countries SCA is only applied on a voluntary basis, according to an excellent press release from the European Commission.
While the EU member states were to have implemented PSD2 by January 2018, SCA will become mandatory 18 months later after the EBA Regulatory Technical Standard (RTS) after the date of entry into force of the RTS (which is anticipated to be later this year). So in essence, we are looking at mid-to-late 2019 (September 2019 was one such date some documents have quoted). This will allow all stakeholders sufficient time to incorporate SCA and other security requirements into their systems and workflows.
2FA for SCA
Given the SCA timeline, 2018 is a perfect time for businesses to begin implementing 2FA solutions to account for the required increased security. The international law firm Taylor Wessing, in their paper: Strong customer authentication under PSD2, notes that the “The EBA agreed with the majority of respondents to the Consultation Paper that, in order to ensure technology neutrality and allow for the development of user-friendly, accessible and innovative means of payment, it should not define the authentication elements further.” This means that the EBA does not specify the manner in which 2FA may be implemented. There are a variety of schemes including token delivery over mobile channels such as SMS or push notifications or more traditional email channels, as well as TOTP soft token solutions and others.
All of this noted, we should point out that, like any good 2FA implementation scheme, there are some limitations and specific regulations and these need to be carefully considered.
Authentication codes
The RTS notes that the generation of an authentication code meets the following conditions:
- No information regarding the knowledge, possession, and inheritance can be derived from disclosure of the authentication code;
- It is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated;
- The authentication code cannot be forged.
Additionally, the RTS states that no more than 5 failed authentication attempts should be attempted within the time to live of the code and that the maximum time without activity by the payer or user after being authenticated for accessing its payment account online shall not exceed 5 minutes.
Dynamic Linking of the transaction
The RTS indicates that electronic remote transactions – essentially payments made over Internet (whether on a desktop device such as a laptop or mobile device) must include elements that “dynamically link the transaction to a specific amount and specific payee.” The RTS considers this an additional form of SCA.
For this SCA requirement, the amount of the payment transaction as well as who the payee (or merchant) should be provided back to the user at the time of a 2FA transaction.
If there is any change in amount or payee, another authentication code should be generated (e.g. “dynamically linking” that code to the new payee and/or payment amount). An SMS message with all the required information may look like the image at the right: The 10-minute security code, the merchant’s (or payee’s) name and the amount of the transaction.Interestingly, an authentication code generated by a third-party TOTP-compliant app such as Google Authenticator are generated completely separate from the payment / merchant information and therefore cannot be dynamically linked.
Channel Independence
This requirement is a bit tricky. The RTS states that the “payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.” A multi-purpose device could be a mobile device or tablet, or even a laptop.
If a user is on a laptop and is requested to make a payment, then that merchant may send an SMS to the user’s mobile device with the payee (e.g. the merchant) as well as the amount they are going to pay, along with the authentication code in the body of the SMS.
In another example, if the user is using a mobile device to interact with a merchant and initiates a payment, then this channel independence does not specifically prohibit SMS or any mobile-specific delivery channel. Here, it is a fine line. In many cases, the only device a user has is a multi-purpose device such as a mobile phone. But, channel independence is just that – an independent channel on the same device – an SMS with an authentication code is a different channel (in fact, it is an out-of-band channel, reached via the mobile telephone number) than the mobile app or web browser the user is engaging with the merchant. The same channel independence would apply to using mobile app to generate a TOTP-compliant code (such as Google Authenticator), but as noted previously, the TOTP-complaint code fails the dynamic linking of the transaction.
Conversely, if the user was using a mobile app to access the merchant, then a push notification to that same app (with the authentication code) would not be possible, as they are the same channel.
There are those who would say that 2FA over SMS is very unsecure and in some cases, that could be true. Yes, there were some isolated instances where an attacker managed to access 2FA SMS messages via SS7 on one operator; however, many of these vulnerabilities have been closed. Additionally, it very much does matter how the authentication code is generated and provided to the user and how the messaging service provider delivers such codes.
In situations where multi-purpose devices are prevalent (and today, these are and will continue to be the most prevalent devices), a mobile operator provided messaging channel should continue to be a viable out-of-band channel for 2FA tokens.
For a more detailed analysis, I found an informative blog post by Frederik Mennes that provides more details as to what types of scenarios – especially for multi-purpose devices – should be compliant for PSD2 SCA.
PSD2 SCA should not be taken lightly, but many already implemented 2FA solutions should work; however, we also know that many online merchants are not yet providing solutions that are complaint with PSD2 SCA. As of this writing, there is still ample time to incorporate SCA into payment workflows. SAP Digital Interconnect has a solution called SAP Authentication 365 that provides an API based cloud solution to enable businesses to implement PSD2-compliant SCA.
The SAP Authentication 365 mobile service is an end-to-end service that enables you to implement a multichannel two-factor authentication (2FA) service quickly and securely, with authentication tailored to your digital business. It helps protect the identity and data of your enterprise customers by enabling authentication via SMS, email, push notifications or TOTP soft-tokens. The REST API from SAP simplifies generation and authentication of validation or authentication codes and provides flexibility and capabilities to enable implementation of a PSD2-compliant SCA strategy.
Please follow me on Twitter: @wdudley2009
- SAP Managed Tags: