Part 2 of the three-part series “EU PSD2 Strong Customer Authentication (SCA)“.
In the first installment of this three-part series, we introduced the European Union’s European Banking Authority (or EBA) directive called PSD2 (second payment services directive) and outlined some of the guiding principles of strong customer authentication (SCA).
Referring to 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). As noted in Part 1, 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 this post, we will explore the SCA limitations and regulators that implementers must consider. First, let’s look at the authentication codes that are generated. Remember, this is essentially two-factor authentication, or 2FA.
The RTS outlines the following conditions for the authentication codes:
- No information regarding the knowledge, possession, and inheritance can be derived from disclosure of the authentication code. This means that if you know the authentication code, there is no way to derive any other item of knowledge (e.g., a user ID), what the user has in his possession (say a mobile phone – meaning you cannot derive the mobile phone number), or inheritance – aspects about the users themselves, such as biometrics.
- It is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated. For this condition, given any authentication code, there is no way to generate a new authentication code by referencing one or many previous authentication codes.
- The authentication code cannot be forged. The implementer must create authentication codes so that forged or fake codes cannot be successfully validated.
- No more than five failed authentication attempts should be attempted within the time to live of the code. Each code generated will have an expiration time or “time to live.” This timer starts immediately after the code was generated and includes delivery time. A good rule of thumb is that the code should expire in 15 minutes or less. Some organizations take this to 30 minutes or one hour, but this may be too long. If the user attempts to authenticate with the code and fails five times, then a new code must be sent. This prevents any type of brute-force attempt to figure out the code.
- The maximum time without activity by the payer or user after being authenticated for accessing its payment account online shall not exceed 5 minutes. This is a standard inactivity timer and while separate from the authentication code, it is a timer that starts once the user is successfully authenticated and does not perform any activity.
These are all relatively standard conditions for the generation/validation of authentication code used in 2FA situations.
Now let’s take a look at the RTS requirement called dynamic linking of the transactions. Electronic remote transactions (e.g., made over the Internet, regardless whether the device was a desktop or a mobile device) should include elements that “dynamically link the transaction to the specific amount (of the payment) and the specific payee.”
This SCA requirement indicates that the payment amount of the transaction along with to whom the payment is being made should be provided back to the user at the time of the 2FA transaction.
For example, an SMS received by the user would verify the purchase amount and the merchant, along with the security (authentication) code and the expiration information for that code. One thing to note is that the purchase amount and the merchant are not encrypted.
An alternative would be to include a URL along with the security code in the SMS message. The URL would link to the linked, encrypted transaction information – accessible via something the user knows, as well as the security code (received on something the user possesses).
Authentication codes generated by third-party TOTP-compliant apps such as Google Authenticator and many others are completely separated from the payment/merchant information. The ability to dynamically link these codes to the transaction is somewhat troublesome.
Additionally, most of these free apps may not contain the appropriate measures to support dynamic linking of transaction data and to ensure that these apps contain countermeasures to disrupt app cloning as well as jailbreak and root detection. That said, there are some specialty SDKs and APIs that can provide these countermeasures to compliant mobile apps.
This means that an authentication code generated by a third-party TOTP-compliant app such as Google Authenticator are generated separately from the payment/merchant information and therefore cannot be dynamically linked.
The Channel Independence requirement 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.”
The multi-purpose device may be a mobile device, tablet, or laptop. In fact, there will likely be scenarios in which the banking/payment app and the authentication app are on the same device. In a few cases, they could be part of the same app. Alternatively, the payment app could rely on an out-of-band authentication channel (like SMS).
Channels refer to the means of interacting with the user. The channel for the user’s online payment (or payment account access) and the channel used for authentication must not be the same. In terms of the available device combinations that are in the marketplace today, channel independence brings up a number of issues. The out-of-band authentication via SMS is widely deployed, easy to use, and quite popular among consumers; however, it does have some perceived security issues.
Besides out-of-band solutions such as SMS, another good channel independent and workable solution would be to use a push messaging via a separate cloud authentication solution to a mobile authentication app or even the banking/payment/merchant app with the payment information as well as a unique code.
A separate authentication app that incorporates the appropriate countermeasures, receiving dynamically linked information through an encrypted, independent channel is another possible method to satisfy these requirements.
In part three of this three-part series, we’ll outline some SCA implementation options that should satisfy the requirements outlined in the RTS, as well as some places to find more information.
Please consider following me on Twitter: @wdudley2009