Meeting PSD2 requirements with FIDO-based authentication

The Directive officially introduces the Payment Initiation Services Providers (PISPs) and Account Information Service Providers (AISPs), specifies their roles and defines when strong customer authentication (SCA) is required and how strong should it be.

While the first aspect “paves the way for significant changes to the payments market”, the second one aims to improve security. Obviously we have to find technological solutions that meet the requirements on strong customer authentication and at the same time support the concept of PISPs and AISPs.

Security Aspects

European banks - considered payment service providers - are already using two factor authentication such as SMS-TAN in Germany and HW-OTP in the UK. With a focus on 2FA already in place, some may ask why is there any need for the changes specified by PSD2 now?

Attacks like EuroGrabber and others have shown that our traditional approach of using one-time-passwords (OTPs) is not strong enough. This is reflected by government standards that limits password plus OTP to a technique known as AAL2. The specific implementation of OTP using SMS is even on the way to become deprecated.

A single FIDO Authenticator implementing user verification using PINs or biometrics meets the requirements of strong customer authentication when implemented in a Secure Execution Environment. Therefore, stronger and more convenient authentication methods are available in the market today. (A more detailed understanding is found here: FIDO PSD2 Whitepaper.)

The FIDO protocol provides protection against phishing and man-in-the-middle (MITM) attacks.

Practical Solutions for PISPs and AISPs

Today, some PISPs or AISPs work like this:

PISPs ask the user to enter their credentials (username, password and OTP) and then send it to the user’s payment service provider. They analyse the web page provided by the payment service provider and provide their service to the user based on that. Unfortunately, there are two issues with this approach:

a) Some banks disallow their customers to share the banking credentials with anyone

b) Users cannot distinguish legitimate PISPs and AISPs from malicious attackers as seen in the illustrations above. Typically payment service providers would try to convince users to look for the HTTPs padlock, verify the green bar indicating EV certificates, check the URL to match the bank’s name etc. Studies have shown that users are not very good by following such practices, but actively endorsing a pattern violating those advises doesn’t seem to be a good idea.

This approach doesn’t work anymore when users use strong customer authentication as defined by PSD2 and the related RTS. One requirement is that “the authentication code shall be accepted only once by the payment service provider when the payer uses the authentication code to access its payment account online”. Another requirement is that “payment service providers shall ensure that the risks against misdirection of communication to unauthorized parties in mobile applications and other payment services users’ interfaces offering electronic payment services are effectively mitigated”.

But we can do better! Let’s see how PISPs and AISPs can work when using strong authentication:

1. Users would initially authenticate to their payment service provider providing the authentication code as defined by the RTS and ask them to issue an Access Token (as defined by OAuth2, e.g. section 4.1).

2. The user would give that Access Token to his trusted PISP or AISP.

3. The PISP or AISP would present the Access Token to the payment service provider and be granted access to the extent defined by the user in step #1. This is a proven pattern in the internet today and allows the payment service provider to understand that the user grants some limited access to some other entity. The scope of that access is controlled by the user and enforced by the payment service provider which yields yet another advantage over today’s Screen Scraping approach.

The new PSD2 requirements bring a new set of opportunities and challenges to European payment service providers. Fortunately, the FIDO Alliance and the team at Nok Nok Labs is aware of the details and deeply engaged in bringing robust solutions to market to drive modern authentication success around the world.

About Dr. Rolf Lindemann

Rolf Lindemann works for Nok Nok Labs as Senior Director Products & Technology and brings more than 15 years of experience in product management, R&D and operations from the IT security industry. Prior to Nok Nok Labs Rolf worked as Senior Director Product Management in the user authentication group at Symantec where he was responsible for research and product strategy on device authentication in smart grids and mobile networks.

Rolf Lindemann received his PhD from the Technical University in Hamburg-Harburg and holds a masters degree in electrical engineering.

About Nok Nok Labs

Nok Nok Labs provides organizations with the ability to bring a unified approach to deploy easy to use and secure authentication infrastructure to their mobile and web applications, using standards-based solutions that include support for FIDO and other specifications. The Nok Nok S3 Authentication Suite enables organizations to accelerate revenues, reduce fraud, and strengthen security and privacy. Nok Nok Labs is a founding member of the FIDO Alliance with industry leading customers and partners that include NTT DOCOMO, PayPal, Alipay, Samsung and Lenovo. For more information, visit www.noknok.com.