Fraud and Security: 2FA Considerations for PSD2

Strong authentication requirements updated

The idea of PSD2 is to give consumers more rights with their data and security. Before PSD2, if a user had a weak password and was hacked, it was the user’s fault and their issue. Hopefully, the firm worked with the user to restore any losses that occurred from the hack for the sake of PR alone. However, the new directive puts the responsibility of strong customer authentication (SCA) on payment service providers and their partners. Yes, that means that if a user has a weak password, no two-factor authentication, and is hacked, blame is placed on the firm providing the service. And the firm must restore any loses the customer encountered by the next business day.

Change signup and login processes to force 2FA

The shift in responsibility will likely encourage any firm that handles payments, or sends and receives funds in any way, to force two-factor authentication. While the number of firms offering 2FA has increased in the last few years, it’s often hard to find where to enable it and it’s not necessarily encouraged; rather, the option is there if the user wants it, somewhere in the account settings. Users who do not use 2FA see it as inconvenient and do not believe that they are at risk (they are though.) Thus, firms do not want to force 2FA.

It’s time to change that.

The basic definition of “strong customer authentication” is presented in article 4(30) of PSD2. It states that authentication must be based on the use of two or more possible authentication elements, categorized as:

  • Knowledge (i.e., something only the users knows, such as a password)
  • Possession (i.e., something only the user has, such as a token or device)
  • Inherence (i.e., something only the user is, which a fingerprint or a face scan proves)

How does a firm “force” 2FA? Well, take two elements from the list above: knowledge and possession. As the username and password is already part of the sign up and login process (knowledge,) require that users provide a mobile phone number so that the service could send an SMS PIN code to the device (possession.) If current users have not provided a mobile phone number, ask for it with their next login and verify the number immediately.  

Next, direct the user to the account page, encouraging them to use a time-based one-time password (TOTP) app like Verigator and begin using TOTP codes to authenticate. This part would be difficult to force, but TOTP is more secure than SMS PIN codes. However, SMS is better than only using a password and proves possession. Also, the authentication process can trigger an SMS PIN code every time a user logs in, no matter what, so it’s simple to get this process started as a bare minimum for 2FA.

We've always recommended that users use 2FA every time they log in and again when they execute a sensitive transaction, like a payment. In January 2018, 2FA will be mandatory by law. 

And firms don’t have to build this from the ground up. We have the tool set ready to be deployed –both TOTP and SMS with one API, the 2FA user interface (yep, doesn’t have to be built either,) and a user app that syncs any service users use that also uses our API, automatically.

Raili Liiva
2017-10-10 00:00:00 UTC