The latest installment of our series focused on Strong Customer Authentication (SCA) explores the aspect of dynamic linking. How is this component vital to providing secure online transactions?
In a nutshell, dynamic linking within SCA can be thought of as the mechanism that pairs authentication codes (which we’ve previously covered) with specific payments.
Unlike Google Authenticator, in which authentication codes are generated without any connection to a given transaction, dynamic linking provides better assurance for customers to be aware of which payment they confirm when using Face ID or entering a PIN code.
Dynamic Linking Requirements
Within this article series on SCA, we continue to refer to the Official Journal of the European Union, which contains information on Regulatory Technical Standards (RTS) and serves as the authoritative resource on each of its related requirements. Let’s take a look at the requirements related to dynamic linking described in the EU’s corresponding journal entry. The four main requirements related to the ins and outs of dynamic linking are as follows:
1. The payer is made aware of the amount of the payment transaction and of the payee.
2. Any generated authentication code must be specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction.
3. The authentication code accepted by the payment service provider must correspond to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer.
4. Any change to the amount or the payee will result in the invalidation (and failure) of the authentication code generated.
In addition to these points, it’s mandatory that “confidentiality, authenticity and integrity” of the transaction amount, payee information, and the generation, transmission, and use of an authentication code is maintained throughout all of the phases of the authentication. This requirement is related to secure communication channels (for example, using TLS/SSL) and secure execution environments (for example, when making transactions in mobile apps).
This ensures that the payer remains aware of what they’re executing throughout each transaction that they make, and it also prevents a number of digital threats from taking place during the course of online transactions.
Dynamic Linking in Batch Payments
The existing legislation on dynamic linking remains concise, and in addition to the points mentioned above, the guidance for other payment scenarios — for example, batch payments — is minimal. The related requirements are described as follows:
...in relation to payment transactions for which the payer has given consent to execute a batch of remote electronic payment transactions to one or several payees, the authentication code shall be specific to the total amount of the batch of payment transactions and to the specified payees.
— PSD2 Regulatory Technical Standards, Article 5 - Dynamic linking, Paragraph 3b —
The practical issue here is that a batch payment can contain a hefty number of transactions. If we consider 5,000 transactions to be made, each in a different currency and with different due dates, then what’s considered to be the total amount? And how do you show 5,000 transactions?
Here’s the feasible way to deal with these cases:
- First, it’s necessary to prepare the sums of transactions in each currency and notify users about these sums in both web and mobile apps.
- Next, calculate the challenge value by hashing account numbers, amounts, and currencies (sorted alphabetically) and display the challenge in both web and mobile apps.
- Finally, show any other relevant batch payment information, such as the payment count, to help the user understand the context.
What Happens When Linking Goes Wrong?
Simply put, without dynamic linking in place, it can be possible for attackers to obtain authentication codes and wrongfully use them for a different transaction or purpose.
To put the importance of dynamic linking in perspective, it’s helpful to identify vulnerabilities associated with a lack of this security measure in place. In these scenarios, the main type of attacks arise when cyber-criminals insert themselves within transactions between payers and payees by utilizing social engineering techniques such as session hijacking attacks.
Due to the way that dynamic linking works – and more specifically, the fact that authentication codes will dynamically fail if a transaction’s amount, details, or payee information have been at all modified – these types of attacks aren’t possible when dynamic linking is applied.
To succeed against the dynamic tactics of cybercriminals, companies must take the steps necessary, such as implementing SCA measures like dynamic linking, to ensure that the fortress surrounding their financial apps is as impenetrable as possible.
Next up in our SCA series, we’ll be taking a look at the details and independence of elements. Until then, stay secure!
.webp)
