Credential sharing — the real problem with screen scraping

There is a bizarre argument happening in the fintech world at the moment, tech leaders & regulators from across Europe are arguing that the sharing of online banking credentials is good practice and should continue indefinitely.

This is down to quirk of history where a hack to get around poor bank services became entrenched. Because banks didn’t actively block this hack, they effectively condoned it. And as time went on regulators started to protect the companies using this hack as they were providing valuable services for consumers.

Although we are (finally) moving towards banks providing APIs — bizarrely some of these APIs will support third parties collecting online banking credentials from end-users and submitting them to the bank via the API.

To understand why asking a user to hand over their online banking credentials is a hack, lets start by taking a look at the different types of credentials that a bank issues its customers:

  • Debit card — the numbers on the debit card are a set of credentials that are issued to end users specifically to make payments via third parties whether at a physical location, online, or via phone.
  • Online banking credentials — for the end-user to get account information and make payments via the bank’s online banking interface or mobile app.
  • Telephone banking credentials — for the end-user to get account information and make payments via a phone

So banks provide a set of credentials for making payments via third parties (debit cards), BUT they don’t provide any credentials to access account information via third parties. In addition there are limitations with the credentials they provide for making payments:

  1. No strong customer authentication. The use of the numbers on a debit card when making an online payment doesn’t give a strong assurance that the owner of the debit card is making the payment, hence the persistent levels of fraud associated with card payments.
  2. No “dynamic linking” or “incremental auth”. The same debit card number can be used to pay for a holiday of £10,000 and a coffee of £3.
  3. Cost to use these credentials. This is due to the fact that there are multiple parties in the chain between the end-user and the bank (e.g. card networks, acquirers, processors, merchant accounts, etc.). In addition there is a higher risk of fraud due to the fact that there is no strong customer authentication — this in turn increases the cost of accepting card payments.

Because of the cost of using the payment credentials and because banks provided no credentials to access account information via a third party, the market created a “hack”. Fintechs built technology that could allow the use of online banking credentials with third parties. The third-parties would log-in to the online banking interface impersonating the end-user. The services built on these hacks have grown in popularity over the last 10 years due to customer demand. Third-party fintech firms have been able to provide low cost payment services and useful personal finance tools.

If banks were more technologically adept and wanted to better serve their customers, they would have seen their customers using these hacks and would have provided technical solutions to avoid the need for the hacks. Banks have been complicit in the rise of screen-scraping. Even though the use of such services is against the terms of service of many banks, most have turned a blind eye. Some banks tried blocking screen-scrapers but faced complaints from their users and stopped blocking. Because this has gone on for so long, it has become entrenched and the companies making use of online banking credentials have started to be protected by regulators and lawmakers.

What are the problems with the re-use of online banking credentials?

  • Those credentials are issued for the sole use of the user on the bank’s online banking or mobile interface.
  • Sharing login credentials is inherently bad security practice.
  • It removes non-repudiation, i.e. if I have given my credentials to someone else then that person can impersonate me. The bank doesn’t know if it is dealing with me or someone I’ve shared my credentials with.
  • It increases the chances of phishing attacks — if customers get used to entering sensitive credentials on multiple sites they will become desensitised to phishing attacks
  • Passwords should be unique per site and not re-used: entering the same set of credentials on multiple sites is bad practice
  • There is a greater risk that the credentials are compromised
  • There are a large number of capabilities available via online banking interfaces, a user will rarely, if ever, want to give a third party access to. However by sharing their credentials they have done so.
  • It is impossible for the end-user to revoke access to a single third party they’ve shared their credentials with. If they want to revoke access they need to change their password

Debit card credentials suffer some of the above limitations, but they are designed to be used with third parties. There is a strong, contractually and legislatively backed, liability framework that supports them.

Online banking credentials are not designed to be used by third parties. Fintechs (including my company) have used them to allow us to provide valuable services to users. But we have used them because there was no other option, not because its best practice. We have protected end-user credentials and thankfully there hasn’t been a major breach at any fintech performing screen-scraping. This doesn’t mean that we want to continue screen-scraping indefinitely though!

Some fintechs pretend that the re-use online banking credentials isn’t a hack, their arguments include:

Entering your credentials into a fintech app is the same as entering your credentials into a browser

At one level this is true. The user never enter’s their credentials directly into the bank’s server. There is always software in between the bank and the user. I would argue that there is a difference between “first party” software that is on a device controlled by the user and “third party” software that is on devices not owned or controlled by the user.

A browser or a password manager is software that I choose and manage on my own device. Good password managers are designed in such a way that even if the passwords they store are sent to the cloud they are encrypted such that only the end-user can decrypt them. This is not the case for services that act as a man-in-the-middle between the user and an online banking interface — they need access to unencrypted credentials.

When I use a browser I am putting a lot of trust in that browser. The browser negotiates an encrypted connection between myself and the secure websites I’m interacting with (e.g. my online banking interface). The same is true if I use an app provided by my bank. While browser vendors aren’t regulated, browsers face continual rigorous scrutiny from security professionals. If a browser was ever found to be harvesting banking data or credentials it would be game over for that browser. That trust could never be regained.

This argument is clearly a case of false equivalence.

So long as a third party identifies itself, it is secure and PSD2 compliant

Third parties identifying themselves is good practice, but still doesn’t change the fundamental issue that re-using online backing credentials is a hack. PSD2 calls for identification of third parties, but it also calls for “strong customer authentication”.

Some methods of strong customer authentication involve a customer using “touch id” or similar on their mobile device to unlock a private key that is used to sign challenges received from the bank server. Such methods provide a good mix of usability and security, but are incompatible with credential sharing.

Credential sharing can only be used with “knowledge” based elements and “inherence” or “possession” based elements that can be represented by a human readable code (e.g. from a pin-sentry device). Therefore by requiring banks to support credential sharing for any method of access reduces the strong customer authentication methods available for a bank to implement (especially the higher security methods).

Furthermore, the definition of a knowledge based element is that it is something only the user knows. Once it has been transmitted through (and potentially stored by) a third party, this is no longer the case.

Some players in the market argue that because they are regulated and will keep logs of each use of the credentials then its all above board. However logs can be tampered with, credentials can be siphoned by rogue employees, and correlating logs from a bank and a large third-party is a time consuming and error prone exercise. If there were no better technical solution then we would have to live with audit logs as a protection mechanism. However granting third parties secure access without sharing credentials is a solved problem with numerous tried and tested international standards.

Redirection = Bad UX

Fintechs also complain that there will be a poor user experience if users have to be “redirected” to the bank in order to enter their credentials. This argument is flawed on a number of levels:

  1. Many fintechs already use a redirect model themselves. For example when a user pays with Sofort they are redirected away from the merchant to Sofort and then back to the merchant. A redirect based API approach will support a similar user experience, except that the user is redirected straight to the bank rather than to Sofort. Paypal have been succesful and there service works with a redirect model.
  2. The success of “Login with Google” or “Login with Facebook” demonstrates that redirection based user experiences can work well and in many cases are far superior to the continual re-entering of different sets of credentials.
  3. Redirection can provider a better user experience if the user is already “logged in” to the bank. For example if I have a banking app on my phone where I’m already logged in — then I don’t have to re-enter all my credentials, I can simply authorise the request.

Sharing Credentials — A one way street

While I’ve heard many companies clamouring for the right to use banking usernames and passwords, I’ve not heard of any who are willing to reciprocate. Many of these fintechs have their own login credentials and they generally instruct users to keep these credentials private and not share them with anyone.

Outside of the regulated world of finance, credential sharing has been almost entirely stamped out — as it destroys any strong assurance of identity. It is insane that we may end up in Europe with legally mandated, decades old, bad security practices. What is even crazier is that this is in the world of finance — where security requirements should be stricter.

I’ve written before how legislating for APIs was never going to be easy — but things are worse than I thought. In the UK, the Open Banking API Standard took the bold move of only supporting redirection based APIs using tried and tested security standards designed for the 3rd-party access use-case. It is a shame that the standard they have developed may now be challenged in Europe. I get that people don’t like banks and that banks have generally abused their oligopolistic positions — but “removing barriers to entry” or “encouraging competition” should never come at the expense of security & privacy.