For modern payment systems, something a bit more advanced is required: multi-factor authentication. With multi-factor authentication, more than one type of identity factor is involved, which significantly increases the effort required to break the security of the solution.

In the PSD2 RTS, the requirement to use multi-factor authentication is defined in article 4:

“Where payment service providers apply strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication shall be based on two or more elements that are categorised as knowledge, possession, and inherence and shall result in the generation of an authentication code.”

Authentication factors are traditionally split into these three categories: knowledge, possession, and inherence. Each of these categories gets a separate article in the PSD2 RTS:

• Knowledge refers to typically a PIN or a password. In article 6 the payment service providers are required to mitigate disclosure of the knowledge factor.
• Possession can be either a token used for authentication, but it can also be the possession of a device if it has earlier been proven that the device belongs to a user. In article 7 the payment service providers are required to mitigate replication of the possession factor.
• Inherence is basically “metrics intrinsically owned by an individual”. This is typically fingerprint, face recognition or voice recognition. In article 8 the payment service providers are required to protect access to the inherence factor.

Looking at the different authentication categories, it’s also important to understand how each can come under attack on a mobile device, such as a smartphone.

Knowledge-based authentication is probably the most vulnerable factor, since users have a tendency to use either the same password or variations of the same password. And this same logic can be applied with PINs.

Also, from a practical perspective, it is relatively simple to monitor the screen of a device for “finger presses”, making it easy for the attacker to record the password or PIN. In either case: This allows for attackers to not only automate entry of your password or PIN, and potentially automate transfers using a banking app, which happened with the attack against PayPal. 

Possession authentication can also be attacked. However, the challenge here is that if the data indicating possession is stored locally, an attacker can steal the “data storage” of your app. Then the attacker can run the app under an emulator in a remote location, possibly simulating a real customer.

Many solutions mitigate this by checking information such as serial numbers, but this is not viable since it can also be cloned. It is possible to find a classic recipe for how to exploit this type of vulnerability, simply by copying some files from a device.

While inherence is a strong factor, there are some fundamental problems. The user is often not informed properly, during an authentication, of what exactly they’re really authenticating. If the device suddenly pops up an “authenticate with your fingerprint” dialog, it is quite likely that the user will blindly accept the dialog. A recent attack from last year targeted Apple devices, using this technique. Sadly, it is also not the case that the majority of users have reliable biometric sensors available.

Here is how we at Okay help to mitigate these threats with a Strong Customer Authentication Service:

For threats against knowledge there are several mechanisms which are used:

• We build our own keypad so that we can randomise entry and monitor inputs.
• We use strong mechanisms to check that there are no apps misusing using mechanisms such as the Android Accessibility Service for registering keypresses.
• We check that the device is actually moving as expected during entry of text, as a form of liveness detection.
• All running code executed is run in a secure execution environment, which helps protect against more direct attacks.

For possession we can similarly mitigate the threats:

• We check multiple values in order to verify that the execution environment of a transaction or authentication is the same as before. 
• The checks are also directly linked to the secure storage so that if an attacker manages to steal the data storage they’ll not be able to decode it.

Inherence is a very useful factor when it is available, but there are some steps which should always be taken when using it:

• We make sure to display the input mechanism for inherence at the same time as the details for what the user is actually authenticating is being shown
• Advanced mechanisms prove that “what-you-sign-is-what-you-get”, e.g. by verifying the display showing the transaction information
• And, as mentioned before, we use a strong secure execution environment, so that the app is not simply bypassing the input

Knowledge, possession, and inherence are important for authentication, but it is important to be aware that they are only used for the authentication of the end-user, and that securing the transaction itself will require more than just strong customer authentication.