Controllers and processors should give me access to my data, and give me the ability so that I decide whom to share it with and for what purpose and how much and how long.
In other words, I want data-controllers to provide me with capabilities, that support my rights for data-portability, right of erasure, right to be forgotten, and right to limitation or object to processing at all.
So when it comes to data access... MITM or Screen Scraping... It doesn't matter! It is unsafe and WRONG! Long story short, Use oauth2 on behalf flow instead... Usually with a redirect or just-in-time approval method by the end-user.
Painting the picture
Screen scraping is the process of collecting screen display data from one application and translating it so that another application can display it. This is normally done to capture data from a legacy application in order to display it using a more modern user interface.
However that is not the way it is used most of the time... Instead screen scraping is the automated, programmatic use of a website, impersonating a web browser, to extract data or perform actions that users would usually perform manually on the website.
A man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.
While screen scraping usually refers to a legitimate technique used to translate screen data from one application to another. But lets say you have a legacy application which normally, is either replaced by a new program or updated, but the vendor got bust?!?. Then screen scraping might be an option, and should only be done as a last resort... (lets call it middleware).
Let's discuss bad use-cases
So one of the "legitimate" use-cases, is innovative banking apps. And when I say "legitimate", I mean: Not good at all.
So before we dive into all that what I think is wrong, lets list the problems objectively from an information security perspective and repeat what we have always preached to clients, family members, friends, co-workers... Everyone:
- The credentials issued to you, it's sole use is your user access and only you.
- Login sharing is inherently bad security practice. (and against toc)
- It removes non-repudiation. Some one else (thief) can impersonate you.
- There is a greater risk that the credentials are compromised
- It is quite impossible for normal users to revoke access to a single third party they've shared credentials with. (knowingly or not) If you want to revoke access you need to change your password.
- The mantra: Never share your password(s), applies to everything you hold dear.
When it comes to banking, Screen-Scraping and credential sharing is problematic from MANY perspectives, one being privacy, the other consumer protection... And honestly, where is the bank protecting you? If something goes wrong, it is for one not clear who is responsible... But you the customer, used or shared your credentials knowingly or unknowingly...
EBF has published a video about this today clarifying their stand point which I mostly agree with.
Me narrating the EBF video (harshly)
So what is screen scraping?
Screen scaping can happen when you make an online payment...
Some third party online paypment services ask you for your access credentials including your special bank account codes...
These services then steal your contact details with(out) your knowledge and pretend to be you.
Simple technology can prevent this, but is not used to protect you.
The fraudsters then accesses your bank account...
And they get to see all! the data of your bank account...
This third party will be profiling you...
The service then contact the bank and pretends to be you! The service impersonated you in the authentication process!
Problematic is an understatement
In controlled environments where middle-ware and the application is owned by one and the same party, these kinds of solutions or temporary plug-ins might be a very good use-case, but unfortunately, we see it more and more, this is used in wrong ways to promote innovation. While I highly recommend most of the applications that use this technique from a innovation perspective, I highly urge every single one of them to talk to the party in question and see if API-access with an oauth2-flow, where the user can decide, is possible.
In any case, by "borrowing" your credentials, the 3rd party can read all information about you. The act of screen scraping, should be illegal in my opinion... While there are good reasons for innovation, this should just not be the case.
Normal flow
@startuml
title Authorization Code Grant Flow
participant "Resource Owner" as RO
participant "Client" as C
participant "Authorization Server" as AS
participant "Resource Server" as RS
C->AS: Authorization Code Request
Activate AS
note over AS: Needs client_id, redirect_uri,\nresponse_type=code[, scope, state]
RO->AS: Login & Consent
AS->C: Authorization Code Response
Deactivate AS
C->AS: Exchange Code for Access Token
Activate AS
note over AS: Needs client_id, client_secret, redirect_uri,\ngrant_type=authorization_code, code
AS->C: Access Token [+ Refresh Token]
Deactivate AS
loop
C->RS: Call API with Access Token
Activate RS
RS->C: Response with Data
Deactivate RS
end
@enduml
Potential screen-scraping flow
There are tons of examples out there how this is implemented, but let me paint you one of them. The kind where it isn't even shown that one is basically giving access to the app, by offloading the credentials off-site. (let's call it industry "best-praxis")
@startuml
title ScreenScraper: Authorization Code Grant Flow
participant "Resource Owner" as RO
participant "Client" as C
participant "Evil Client" as EC
participant "Authorization Server" as AS
participant "Resource Server" as RS
EC->C: Initiate Authorization Request
C->AS: Authorization Code Request
Activate AS
note over AS: Needs client_id, redirect_uri,\nresponse_type=code[, scope, state]
RO->AS: Login & Consent
AS->C: Authorization Code Response
Deactivate AS
C->AS: Exchange Code for Access Token
Activate AS
note over AS: Needs client_id, client_secret, redirect_uri,\ngrant_type=authorization_code, code
AS->C: Access Token [+ Refresh Token]
Deactivate AS
note right C: Tokens are scraped
C->EC: Access Token [+ Refresh Token]
loop
C->RS: Call API with Access Token
Activate RS
RS->C: Response with Data
Deactivate RS
end
loop by Evil Client
EC->RS: Call API with Access Token
Activate RS
RS->EC: Response with Data
Deactivate RS
end
@enduml
Prevention
So lets get back to the examples of stolen temporary credentials. How could we prevent this? Well, by introducing origin verification in the authentication process and/or mutual authentication on the network layer. Temporary credentials saved and used, should be signed and have an origin verification in it.
As an attack that aims at circumventing mutual authentication, or lack thereof, an MITM attack can succeed only when the attacker can impersonate each endpoint to their satisfaction as expected from the legitimate ends. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. By introducing origin verification, this becomes much harder.
Good example of this is Yubikey 5 with FIDO2.
Companies which changed their business model, would have provided technical solutions to avoid the need for others to create bad solutions. In the case of financial institutions, they would have helped banking and innovation by supplying open-api's for customers to access their data, and/or give them the capability to share their data with "on behalf-of" features where non-repudiation and strong authentication is applicable.
However this is not the world we live in. Fintechs "resorted" to hacks instead of talking to banks... And if they, the banks, were adapt, they would have seen their customers use these apps and be subjected to these hacks... One could state that banks have been complicit in the rise of screen-scraping. Maybe very harsh words but it is true! If you read the acceptable use policies of most banks, you will see it is against the terms of service.
While some institutions did put a stop to it, by actively blocking and protecting customers, these were called hindering (and/or stand in the way of innovation) as they did not provide a good alternative, to which I can agree as I still don't have a way to decide, and easily share, my data.
But how can we perhaps solve this even better? There are open banking initiatives, open apis and PSD2 opening up the potential for information sharing, is upcoming, but honestly, PSD2 is just a mini-version of what I believe should already be deemed as: access to my data, which I decide on.
My advice to banks? Start providing open-api's based upon open-auth2. Give me an option inside my online-banking to enable access to a registered "client" (third party connector-app) or via a redirect screen and ask me which categories and which bank details I want the other party to see in clear UX-design, which is simple and easy. Nothing by default tagged or filled in, but there should be an easy way of simply sharing some or all or remove the access per app and specify how long I want others to keep my data, so that my wishes are known via my bank to the third party, so I don't need to worry about that. Start enabling innovation. Build trust by being my bank that shows me, you hold my data, and I can trust you with it, because you deserve it.