Multi-factor authentication: Knowledge, inherence and possession
The most traditional way of authenticating to a service is to simply use a username and a password. This is what is known as single-factor authentication. If the password is revealed then the security is broken. For modern payment systems something 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.
Multi-factor authentication requirement
In the PSD2 RTS the requirement to use multi-factor authentication is defined in article 4:
1. 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 which are categorised as knowledge, possession and inherence and shall result in the generation of an authentication code.
Authentication factors categories
Authentication factors are traditionally split into these three categories: knowledge, possession and inherence. Each of these gets a separate article starting with article 6:
- Knowledge is 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 tokens 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 are “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.
How can the individual factors come under attack on a mobile device, such as a smartphone?
- Knowledge is probably the most vulnerable factor. Users have a tendency to use either the same password or variations of the same password, and same case with PINs. Also, from a practical perspective it is relatively simple to monitor the screen of a device for “finger presses”, so that an attacker can record the password or PIN. In either case: This allows for attackers to automate entry of your password or PIN, and potentially automate transfers using a banking app. Here is an example of a similar type of attack against PayPal.
- Possession can also be attacked. The challenge here is that if the data indicating possession is stored locally an attacker can steal the “data storage” of your app and then run the app under an emulator in a remote location, possibly completely simulating a real customer. Many solutions mitigate this by checking information such as serial numbers, but this 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 what 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. Sadly, it is also not the case that the majority of users have reliable biometric sensors available.
Threat defense with Okay
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 randomize 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.
- And last but not least, 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.