How Twilio Can Help with Strong Customer Authentication in PSD2

How Twilio Can Help with Strong Customer Authentication in PSD2

This is the second of a three-part series of posts detailing PSD2: Strong Customer Authentication in the EU (SCA).

In the first part of this series, we looked into PSD2’s requirements for dynamic linking, and established that Two-Factor Authentication (2FA) can be used for Strong Customer Authentication (SCA). In this piece, we’ll look at the different types of 2FA you can use with Twilio’s Authy API and how it can help you meet dynamic linking requirements.

Authy is a fully featured authentication API that makes it simple to add 2FA or passwordless login to your applications. It supports One Time Passwords (OTP) sent via voice and SMS, Time-based One Time Passwords (TOTP) generated in the free Authy app or via an SDK, and push authentications via the same Authy app or SDK. This article covers both push authentication and OTP via SMS and voice. TOTP will be covered in the next blog post.

Push Authentication

In order to improve the security of card-not-present transactions, Strong customer authentication has requirements that go beyond typical 2FA. These include:

• The payer be shown the transaction amount and the payee to whom the payment is being authorized
• Each authentication code be unique and specific to that transaction

There’s also an additional recommendation that the authentication code be delivered via a secure channel, to prevent man-in-the-middle attacks.

Of all the 2FA methods available today, push authentication is the best way to address these authentication requirements. It allows you to send a push notification directly to the payer’s device, alerting them that an authentication request has been made. Payers then view payment details, such as transaction amount and recipient info, and approve or deny the payment with a single touch.

Push authentication in the Authy API also assigns each authenticated transaction a unique identifier (UUID), ensuring that each transaction corresponds to a unique authentication code and cannot be used for any other transaction.

Additionally, since communication between the user’s smartphone and the Authy API is encrypted end-to-end and cryptographically signed, the entire authentication flow takes place over a secure channel. It’s the simplest and strongest authentication method and is available via an SDK to embed the features in merchants’ or banks’ own mobile apps. Furthermore, it simplifies the user experience by not asking the payer to re-enter awkward codes, or toggle between different apps.

In terms of striking the right balance between user experience, security and regulatory compliance, push authentications are the best approach to implementing SCA.Let's take a look at each step of a payment where push authentication is used, and also how the Authy API handles every step on the back end.

What About SMS and Voice?

Push authentication may be the simplest and strongest way of authenticating payments, but the most common form of 2FA is to use a One-Time Passcode (OTP) via SMS. But security issues with SMS (e.g., SIM-swap, SMS interceptions) have earned it some bad press of late, and the requirements for dynamic linking might prove challenging for SMS-based authentication. Still, there is a role for SMS, and even voice, in PSD2 protected payments.

SMS and  is valuable as a secondary option because not everyone owns a smartphone on which to download apps and receive push notifications. Furthermore, people with smartphones are not always connected to the internet, such as when traveling abroad. Yet everyone can receive an SMS on their mobile phones, and even more people can receive a voice call. Both SMS and voice are great options to fall back on when a push authentication isn’t possible. But there are some things you need to consider in order to use SMS-based authentication within PSD2 guidelines.

First of all, there’s the requirement that data exchanged must be encrypted. While SMS network communication is often encrypted, the actual contents of an SMS are not. Does that mean that SMS is not a valid code delivery channel? What about voice? Let’s look at the language within the PSD2 directive that would pertain to SMS and voice:

“Account servicing payment service providers, payment service providers issuing card-based payment instruments, account information service providers and payment initiation service providers shall ensure that, when exchanging data by means of the internet, secure encryption is applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data, using strong and widely recognised encryption techniques.”

Since SMS and voice messages are sent over the telephony network, and not over the internet, encryption is not required. Thus, SMS and voice are permitted as code delivery channels.  

Next, the payer needs to see transaction information when authenticating. This can be done by including the transaction ID in the body of the SMS or spoken via the voice message. When using the Authy API, this can be done by using an action parameter.

For example, the payer is on the checkout page, and is shown transaction information. Then an SMS containing the security code and the same transaction information is sent to the payer’s mobile phone. The payer sees the SMS and has the opportunity to confirm the recipient and the amount before authenticating.

Voice-based code delivery also allows the PSP to assign unique identifying information to each message (i.e the sender can associate each code with a transaction) which can be communicated to the payer using Text-to-Speech (TTS). It should be pointed out, however, that aside from TTS being limited to certain languages, the user experience of having to listen to transaction information followed by an authentication code is far from ideal and should only be employed when all other options are exhausted.

Adding the action parameter means that the token is good only if validated with the same action, thus the OTP is unique to the individual transaction, which means SMS-based and voice-based OTP can meet all the requirements for dynamic linking. Let’s walk through the steps of an SMS authentication with the Authy API.

Conclusion

The European Union’s PSD2 introduces the dynamic linking requirement for Strong Customer Authentication, creating a new batch of caveats to the typical 2FA implementation. It lays out these technical requirements in order to adequately protect transactions, and combat rising costs of fraud for online financial transactions.

Twilio has been helping organizations secure customer accounts for years. Now, our Authy 2FA API can help you be PSD2-ready, while balancing security and compliance with user experience and scale.

In part 3 of this series, we’ll look at SCA using Time-based One-Time Passcode (TOTP) for scenarios where authenticating transactions can be a challenge. Specifically, we’ll dive into a new feature for the Authy API, currently in development, that will meet those use cases while at the same time improving the security of TFA.