Is Google Authenticator Sufficient for PSD2-Compliant Strong Customer Authentication (SCA)?

Let's begin with some background information. The Revised Payment Services Directive (PSD2) is a European regulation designed to enhance the security of electronic payments and protect consumers. A key requirement here is Strong Customer Authentication (SCA), which mandates the use of at least two independent authentication factors, a link between the transaction details and the authentication, and a secure execution environment. We’ve written an introduction to SCA that you can read here. Google Authenticator, a popular time-based one-time password (TOTP) generator, is often used as a second factor in authentication processes. However, it is essential to assess whether Google Authenticator alone is sufficient to meet the SCA requirements outlined in PSD2.

SCA entails the use of two or more authentication factors, categorized as something the customer knows, possesses, or is. These factors include a password, a mobile device, or biometric data. PSD2 mandates the combination of factors from at least two different categories for SCA compliance.

Google Authenticator provides a second factor in the form of TOTPs generated on a user's mobile device. While this fulfils the "something the customer possesses" category, it does not satisfy the requirement for a second factor from a different category. There is also another major issue: PSD2 also introduces the concept of dynamic linking, which ensures the authentication code is linked to specific transaction details. However, TOTP codes generated by Google Authenticator are not intrinsically tied to transaction information. Dynamic linking is typically achieved through transaction data signing, a process that combines transaction details (e.g., payment amount, beneficiary account, merchant information) with the authentication to create a unique digital signature for each transaction.

Transaction data signing typically requires that the user actually sees the transaction data as they’re approving the transaction, which makes it possible to sign the transaction. This signature and the transaction data are sent during the authorization process, creating a strong connection between the authentication code and the specific transaction details.

Another potential challenge is that when using Google Authenticator for SCA the use is governed under the rules for “personalised security credentials” defined in the PSD2. Among other requirements in the PSD2 this type of credential is required to be issued in a secure manner, to be tied to the identity of the payment instrument holder, and to be kept secure. Google Authenticator would most likely fail to fulfil these requirements.

There are situations where using Google Authenticator as an extra factor can be useful. An example here is situations where you want a quick solution to secure a website where an attacker has no monetary reason to try to break the authentication process. Here Google Authenticator can serve as a valuable second factor to secure the login. But, Google Authenticator alone would not fulfil the SCA requirements outlined in PSD2, where it is used to protect your financial transactions. To do that you need the following:

1. Two out of three distinct authentication factors
2. A link between the transaction details and the authentication process
3. A secure execution environment where the authentication process can take place

If you’re interested in reading more about this topic we’ve got plenty of information on our blog: okaythis.com/blog