What You Should Know about Strong Customer Authentication (SCA)

With the arrival of the 14th of March PSD2 (Second Payment Services Directive) has made itself heard in a big way. By then, banks had to have their ‘dedicated interface’ (open API) ready for testing by PISPs and AISPs.

As the first deadline dropped, focus rapidly shifted to the second looming deadline on the horizon - September 14, 2019 - the last date of compliance for PSD2 and RTS as a whole. Thus, the questions of Strong Customer Authentication and communication come into play as they are the keys points of focus for this deadline.  

How did we get here?

With the overhaul of the legislation pertaining to all things data and data handling, mainly via GDPR and PSD2 (the first replaces a 23-year-old document, the second a 12-year-old document), the aim of the EU was to bring replacements to the obsolete pieces of legislation and strengthen the privacy and protection for the EU citizens and residents.

A strong emphasis was put on making sure that all data is handled to a very minimal extent and not shared without permission. Those permissions need to be obtained in a clear and specific way and that the information is stored only when needed, for the minimal amount of time required and as securely as possible.

Here’s where strong customer authentication comes into play. The practical implications are the ones that really matter, for example, authentication codes need to follow these rules:

• No information regarding the knowledge, possession, and inheritance can be derived from the disclosure of the authentication code. This means that if you know the authentication code, there is no way to derive any other item of knowledge (e.g. a user ID), what the user has in his possession (say a mobile phone – meaning you cannot derive the mobile phone number) or inheritance – aspects about the users themselves, such as biometrics.
  
  
• It is not possible to generate a new authentication code based on the knowledge of any other authentication code previously generated. For this condition, given any authentication code, there is no way to generate a new authentication code by referencing one or many previous authentication codes.
  
  
• The authentication code cannot be forged. The implementer must create authentication codes so that forged or fake codes cannot be successfully validated.
  
  
• No more than five failed authentication attempts should be attempted within the time to live of the code. Each code generated will have an expiration time or “time to live.” This timer starts immediately after the code was generated and includes delivery time. A good rule of thumb is that the code should expire in 15 minutes or less. Some organisations take this to 30 minutes or 1 hour, but this may be too long. If the user attempts to authenticate with the code and fails five times, then a new code must be sent. This prevents any type of brute-force attempt to figure out the code.
  
  
• The maximum time without activity by the payer or user after being authenticated for accessing its payment account online shall not exceed 5 minutes. This is a standard inactivity timer, and while separate from the authentication code, it is a timer that starts once the user is successfully authenticated and does not perform any activity.

We also did a webinar a while ago about PSD2 and GDPR

In addition, Electronic remote transactions (e.g. made over the Internet, regardless if the device was a desktop or a mobile device) should include elements that “dynamically link the transaction to the specific amount (of the payment) and the specific payee.

This SCA requirement indicates that the payment amount of the transaction along with to whom the payment is being made should be provided back to the user at the time of the 2FA transaction. 

For example, an SMS received by the user would verify the purchase amount and the merchant, along with the security (authentication) code and the expiration information for that code. One thing to note is that the purchase amount and the merchant are not encrypted.

An alternative would be to include an URL along with the security code in the SMS message. The URL would be linked with encrypted transaction information - accessible via something the user knows, as well as the security code (received on something the user possesses).

SMS is an easy option for account and payment verification 

SMS as used for both account and payment verification is known as an Out-of-Band option (OOB). It’s the easiest and most popular method to consumers and is fully compliant with the rules for Account Access and should be an option for Payments if the payment information is included in the SMS. It also meets the requirement of channel independence. 

Of course, these days, there are some security issues with SMS. However, many of these are somewhat overblown in the press (e.g. SIM-swap, SMS interceptions). If using SMS as an OOB channel for two-factor authentication, consider adding an additional knowledge factor to further secure the account or payment. That will provide extra security against certain SIM-swap or SMS-interception scenarios, should they occur. 

These are just two practical examples of what RTS has brought to the table and a tool that can help with the account and payment verification management - SMS. There are many more to come though, and we’ll cover additional ones in more detail in our blog.