Okay LogoOkay Logo
Go back to Okay blog

Security Vulnerabilities Through the Payment Process

First published: 22/09/2020

updated: 21/10/2022

artifact

For the last few years, Okay has been laser-focused on one particular part of the payment process: Strong Customer Authentication (SCA); the process to authenticate and authorise payments. However, authentication and authorisation are not the only vulnerable phases in the payment process; there are several other phases, where each phase has its own unique set of vulnerabilities.

Fraud Before Payment Initiation

First off, fraud can happen before the payment is started. This point is actually where most frauds take place. There is a large number of methods used by criminals to trick people into submitting fraudulent transactions, but the two most common are invoice fraud and phishing. Invoice fraud, at its most simple, is fraudulent invoices that are sent to your company for some service that you have not ordered. In the more advanced versions of invoice fraud, a criminal investigates your website, finds references to your existing suppliers and partners, then notifies your company that payment details have changed, providing their own account details instead. Using social engineering, they might even be able to have an existing invoice be paid to the new account by merely being convincing on the phone. 

Phishing is probably well known to some; in the most basic variant of phishing, customers are tricked into trying to log into a fake website, where they provide credentials. These credentials can then be used by criminals to take over their accounts. Of course, merely having the credentials for an account is not enough to start a payment transaction. However, consider the invoice fraud example: suppose you can leverage phishing techniques to gain access to the invoicing system of a supplier. In that case, you might be able to produce very convincing invoices, and your victims end up making deposits directly into your accounts.

Fraud After Payment Registration

The second phase for fraud can happen once the payment details are registered, which is a relatively «traditional» target for attackers.

By infecting a computer or a mobile phone with malware, the criminals can change a transaction as it is entered, that way the fraudulent transaction is entered instead of the actual transaction. This type of malware attacks dates back to the 1990s, where vulnerable web-based banks were targeted.

Back then, one of the most common ways of identifying a customer was by using a one-time PIN provided by a dongle, as there was no extra verification of the transaction details through the customer authentication process, making the authentication vulnerable to attacks. With the advent of smartphones, this type of attack has been merged with phone malware that tries to compromise the SCA process itself.

Fraud After a Completed Payment

The last phase during the payment process where fraud can take place is actually after the payment has been settled. An example of this type of fraud is chargeback fraud, also known as friendly fraud.

With friendly fraud, a consumer uses their credit card to make a payment, then requests a chargeback on the payment after receiving the service or the product. Typically the merchant will be held responsible, regardless of the measures taken to verify the transaction. In Europe, we have seen this type of fraud for bank transfers as well, as SEPA transactions can be recalled 30 days after settlement by the payer’s bank under PSD2 regulations.

This type of fraud is the main reason why Okay stores as many details about the transaction as possible. We even try including a screenshot of the transaction as seen by the customer when it was confirmed (more about screenshots and GDPR here).

Fraud Attacking Payment Infrastructure

A phase of the payment process that is getting less attention are the vulnerabilities in the infrastructure that receive the payment. There have been several examples where weak server-side controls have given attackers direct access to the payment infrastructure, hitting everything from eWallet providers and cryptocurrency traders, all the way to national banks. The most famous is probably the attack on the national bank of Bangladesh back in February of 2016. 

There are lots of potential traps that developers can fall into when it comes to implementing the security of the back-end infrastructure, everything from low protocol security to internal procedures for access to critical systems. Needless to say, if an attacker can gain access on this level, it is a live-or-die problem for the company involved. Even if the attack does not lead to an immense financial loss, the bad publicity involved can be devastating for a financial institution.

SCA to Fight Fraud

At Okay, our core focus is the SCA process: the process that takes place to authenticate a customer, either to log in to a service or to confirm a payment transaction.

With the increased adoption of smartphones for day-to-day financial management, SCA on smartphones is happening more frequently, and the authentication often involves biometry in some way. We see this process as the most central part of a payment transaction, as in our view, this is the core of the transaction: Without a strong customer authentication, the transaction itself cannot take place.

We have written extensively about the importance of the SCA process, so I will not go too deep into further details here. However, it is important to keep in mind the ways in which criminals can attack the process: by modifying what the customer sees, by stealing credentials and input, or by remotely controlling the application, skipping customer input entirely.

All in All

While it can be depressing how many places fraud can take place, the key take-away from this is that money is a very tempting target for criminals, and if a process can be compromised it most likely will be. Thus, security throughout the payment process is paramount!

Follow us on LinkedIn