Access to Accounts – the great security debate

The Access to Accounts provisions of PSD2 oblige banks to allow third parties (TPPs) to access bank details and initiate payments on behalf of the bank’s customers.

The huge unanswered question is, how can a bank ensure that the access via the third party is really authorised by the bank’s customer?

If this is not done properly, TPPs could be hacked and customer accounts compromised, or fraudulent organisations posing as TPPs could use man-in-the-middle attacks to get money from customer accounts.

Unfortunately the debate is not only about what is best for the customer, and which approach fits which use case, but also reflects vested interests of various industry players. Looking at three possible approaches to customer authentication will clarify this.

Redirect authentication

The first approach is the “redirect” method, also known as OBeP. This forms the basis of the popular iDEAL payment system in the Netherlands.  This allows a shopper on a website to select the iDEAL payment method and choose their bank.

The internet session is then “redirected” to a special page on the bank’s website where the customer enters their normal banking credentials, is presented with details of the payment to be made, and approves it. It’s like when the gas man calls to read your meter, and you let him into your house and supervise him while he reads it.

The benefits of this method include: consumers only have to remember one set of banking credentials, and they only ever enter those credentials on the bank website that they trust. Liability for security problems is also clear, as only one party is involved.

The main downsides are poor usability compared with, say, Paypal; and the limitation of this method to e-commerce via internet browser – it cannot be used on a native mobile app or at a physical point of sale.

The vested interests here relate to the banks. This authentication approach keeps the bank’s brand front and centre of the payment experience, and also allows the bank to apply a type / level of authentication that they see fit.

Overlay authentication

The second approach is the “overlay” approach, also known as screen scraping. This is used by Sofort, POLi and other payment providers. Like the redirect method it allows a shopper on a website to select the Sofort (or other overlay) payment method and choose their bank.

The difference is that the customer stays on the overlay provider’s payment page, where they enter their banking credentials. The overlay provider relays these details to the bank’s website, so to the bank it looks like the customer logging in directly from a browser.

Once logged in to the customer’s internet banking, the overlay provider can access information or initiate payments as required. It’s like giving your house key to the gas man, and trusting him to only read the meter while he’s there.

The benefits of this method include: slightly better customer experience than redirect; customer still has one set of banking credentials to remember; and simplicity, with no technical re-work required by the bank.

Downsides include blurred liability for security problems, plus the same downsides as the redirect method. It also requires customers to enter bank credentials into non-bank websites, increasing the probability of phishing and other hacking attacks.

There are also some technical vulnerabilities specific to the overlay approach. First and foremost is the man-in-the-middle problem where a fraudulent site poses as a TPP’s payment page to gain access to the customer’s internet banking, then proceeds to transfer funds to the fraudster’s account.

Some banks require payments to new beneficiaries to be authorised via a challenge/ response step involving a security “dongle”, but if the challenge and response are passed via the internet session, the fraudulent TPP can simply relay them.

Providing a one-time token via a text message is better, as long as the message includes the beneficiary details and amount, but this doesn’t really work on a mobile device – you don’t want your m-commerce session interrupted by the arrival of a text message or push notification; plus, malicious apps can install themselves to intercept text message, so the one-time token could be made to look as if it related to the bona-fide payment that the customer thinks they’re making, rather than the fraudulent payment that is actually being authorised.

A further technical vulnerability with the overlay approach is that the banking credentials are available in plain text to the TPP. This is unavoidable due to the nature of browser secure http sessions – they are only encrypted as far as the web server being accessed by the browser, in this case the TPP’s website.

The session that the TPP establishes with the customer’s bank is also securely encrypted, but between the two sessions, in the TPP’s server, the credentials have to appear, albeit briefly, in plain text.

A dishonest TPP could use this opportunity to steal credentials, and an honest TPP that gets hacked could inadvertently expose those credentials to fraudsters. A final drawback is that this mechanism only works if the customer provides the credentials in real time when the TPP needs to access the bank account.

For payment initiation this is just about usable – though it precludes recurring payments – but is unusable for a service that needs to access account information on a regular basis, for example to provide the customer with alerts when the balance falls below a specified level.

The TPP could get round this by storing the credentials, but this would not only severely increase the technical risk, it would almost certainly breach PSD2 provision against sharing credentials. The vested interests at play here are primarily those of current and would-be TPPs.

The screen-scraping interface is different for every bank, and needs to be changed if the bank updates its website, so TPPs that have already integrated with a large number of banks see this as a competitive advantage, and would have to write off the investment in that integration if they were forced to use a different authentication method.

Secure delegated authentication

The third method is “tokenization” or secure delegated access. There are open standards for this, notably OAuth.

In a nutshell, the consumer logs in to their bank using their normal banking credentials and gives authorisation for a particular TPP to carry out a specific set of operations on the bank account on behalf of the consumer.

The bank sends a token encapsulating that authorisation to the TPP, who can then present the token when carrying out an operation on behalf of the consumer. It’s like giving the gas man a special key that lets him into the cupboard where the gas meter is, but nowhere else in the house.

PSD2 Authentication 3 DIAGRAM

The benefits of this approach are that it is an open standard which would encourage interoperability between TPPs and banks and potentially other business partners; the consumer or the bank can revoke the authorisation at any time; the customer details are not shared with the TPP, hence eliminating data privacy concerns; and the token can be long-lasting to allow the TPP to retrieve account details regularly, with no customer involvement.

This feature can also be a drawback. The downsides of secure delegated access are that this approach is little used within payments (though widely used by internet giants) so would require potentially investment by banks; and the need for the consumer to memorise a new set of credentials to authenticate themselves to the TPP.

It is also more suited to account information services than to payment initiation services which require an additional authorisation specific to the transaction. The EBA’s SecuRe Pay Guidelines recommend that “Strong customer authentication could include elements linking the authentication to a specific amount and payee” – the “could” might become a “should” or “must” when the PSD2 technical standards are published.

Apple Pay is based on a similar tokenized/delegated approach, proving that the approach can be adapted for non-browser payments usage. Apple Pay uses a secure element to cryptographically link the transaction details with the customer authorisation, providing a verifiable authorization that is much stronger than the one-time token provided by SMS mentioned earlier.

However, Apple Pay does rely on the unique circumstances that the TPP is also able to design a secure device that is guaranteed to have mass consumer adoption, while also having the economic muscle to move the market so both banks and merchants adopt the system.

This is not a model that other TPPs can reproduce. The secure delegated access method is less subject to vested interest arguments due to its small footprint in payments. It seems to strike a reasonable compromise between TPP and bank visibility, and between security and ease of use, allowing a smooth customer journey.