Transaction Authorization Pitfalls – How to improve the current payment ecosystem to protect users and businesses?

This is the first article in a three-part series inspired by my presentation at OWASP Global AppSec in Barcelona. During the talk, I discussed common problems in online payments and how attackers exploit them.  

1. To keep things clear and practical, I’ve divided the content into three articles: How to Improve the Current Payment Ecosystem? – this article. 
2. Examples of Real Vulnerabilities in Payment Processes – coming in July! 
3. Upcoming Changes in EU Online Payments and What They Mean for Security – coming in August!

Connect on LinkedIn!

In this article, I’ll share my thoughts on current internet payment system security problems and propose a few ideas to raise the bar for attackers.

Let me start with the story…

A few months ago, my teenage daughter listed her sweater on a popular second-hand marketplace – Vinted. Ten minutes later, a “potential buyer” messaged her using the chat function that is part of the platform. It was a friendly message about sweater size and wear. Finally, the “buyer” made the decision. After a few minutes, they contacted her again:  “Did you get the money?”  

The marketplace used escrow to protect against non-delivery fraud, and my daughter, a first-time user, was not aware of how it worked. However, “the buyer” explained to her how it should work and helped her check in the right place for incoming transaction. Obviously, there was not any transaction, so “the buyer” showed irritation, pressurized my daughter, and finally sent her a “link” that should point to the correct section in the platform. 

She clicked. A fake but very good copy of the platform appeared. There was an incoming transaction, but it had to be confirmed. Confirmed by… logging in to the bank. She entered her bank login credentials, but it was not working, so the system asked her to provide more information and simulated account recovery. It was very well prepared – the attackers even had a chat on the fake page to “support” the victim. That’s how they were able to extract all the information they needed to steal my daughter’s bank account. 

A few hours later, when I returned home, we noticed that:  

• Her mobile banking app stopped working.  
• An unknown Android phone was paired with her account.  
• Her savings? Gone.  

Why? Because the attackers didn’t just want to steal credentials – they also wanted to pair their own device with her account. Once they did that, they were able to:  

• Authorize all payments.  
• Change limits.  
• Lock her out of her account.  

You may be interested in how this story ends. In this case, my daughter has a dad who is quite familiar with the PSD2 directive. PSD2 enforces a transfer of liability to the bank if the user did not authorize the transaction herself. In our case, the transaction was authorized by the fraudster, so she had the full right to demand full reimbursement from the bank. I did it in her name, but surprisingly, it took us about two years and dozens of letters with the Bank and the Financial Ombudsman to get the money back – more about that in the following article about compliance and reality.

Attacker’s goal 

This scenario isn’t rare. In fact, it’s now the dominant strategy among fraudsters. Why? Because it doesn’t require advanced technical hacking skills, it just involves timing, pressure, and earning the victim’s trust.   

For an attacker, pairing their phone with the victim’s account is the ultimate goal. The current “mobile first” approach to financial apps gives the attacker almost unrestricted access to the victim’s money and data. They can authenticate as the legitimate user and authorize all transactions. Literally, if someone can pair their phone with your payment account, from a bank’s point of view – they become you. The problem gets worse because many systems now trust your identity based only on phone ownership. It opens the door to full identity theft. 

Multi-factor authentication in the mobile-first world 

To discuss possible protection options, we first need to understand where the current weak spots are. The PSD2 directive and similar regulations in the UK, US, and other parts of the world have enforced two-factor authentication. It’s a very good move, but let’s take a look at what it truly means in the era of “mobile first” financial apps. 

As potential authentication factors, we have three options: something the user knows (PIN, password), something the user is (biometry on the phone or behavioral factors), and finally, something the user has (the user’s phone). But how does it work in a typical usage scenario? 

• Most financial apps we’ve tested allow users to increase convenience by replacing their app PIN or password with Face ID or fingerprint. So, the “something the user knows” factor is not used. 
• Biometry checks are not implemented by the app itself. It relies on smartphone subsystems to verify the authenticity of the user’s face or fingerprint. So, the trust is delegated to the smartphone. 

Hence, from all these options, only two remain: user behavior analysis, which is a helpful tool but not an actual authorization factor, and proof that the user owns the phone. 

The question is: how do we actually verify that a given phone belongs to the user and not the attacker? This is the Achilles’ heel of the current payment ecosystem. That’s why account recovery and new phone pairing are key security operations for protecting the entire system. 

How to protect smartphone pairing?  

There are several use cases for pairing a new phone. The most obvious one is pairing it with a banking or payment app for the first time. However, there are others to consider – such as switching to a new phone, pairing multiple devices, or dealing with a lost or stolen phone. All these legitimate use cases have to be comfortable for the user (sorry – business first) and, at the same time, difficult for attackers to bypass.  

We’ve analyzed commonly used methods of proving a user’s identity during the pairing process – both from the attacker’s and usability perspectives: 

We have found that only two of these proofs of user identity during pairing are really difficult to bypass at scale – a visit to the bank and the use of an electronic ID. Unfortunately, visiting the bank is not acceptable in most business cases, and e-ID is still not widely adopted. It’s a good option – but maybe for the future, when the e-ID system is more mature and used by almost every citizen.   

How to protect account recovery? 

Additionally, our app must include an account recovery process in case the user forgets their password, loses credentials, or experiences any issues with logging in. Account recovery is indispensable, but it is similar to phone pairing; it could be abused by an attacker for unauthorized access to users’ accounts. Let me discuss possible options for account recovery: 

• Recovery via another trusted channel – e.g., web or IVR/call center. Probably, it’s the best option, but not for a “mobile first” approach. Some of the current fintech apps don’t even have an option for logging in through web channels or IVR. 
• Recovery codes – such as those used during the generation of cryptographic keys. This is well known for security specialists, but for ordinary users, it will be too difficult. 
• Trusted person – Idea implemented, for example, by Apple for iCloud recovery. The user has to designate the person they trust. If access to the financial system is lost, the user can initiate the recovery process, and this trusted person will receive the recovery code. The idea seems secure enough and quite usable, but it needs to be verified whether it aligns with the legal requirements of financial systems. 
• A trusted source of citizen ID – I mean rather digital functions of e-ID, not video verification of user identity, as these methods are very prone to bypass.

Attacking the face recognition authentication – how easy is it to fool it?

Sebastian Drygiel 2020.11.04 ·12 MIN czytania

All the above options have their usability, trust, or business-related problems, and there is no one turnkey solution that is universally acceptable from both business and user convenience perspectives, as it would be tough for attackers to bypass. Therefore, we need to “raise the bar approach” – not finding one solution that will eradicate all the problems. 

How to raise the bar for attackers? 

Below, I will share some ideas on how we can raise the bar for attackers and still have a system that is comfortable enough for users. These ideas emerged during threat modeling and brainstorming sessions with my team, as well as during discussions following my presentations at various conferences. My goal is to maintain a library of ideas that is both live and current. 

Delay 

When the user pairs a new device with the account, higher transfers and key operations – such as changing limits, security settings, etc.- are disallowed for N days. Even a single day or a few hours of delay will significantly complicate things for attackers, and it will not be very intrusive for users. 

Additional authorization method 

For some time, after pairing the new device, an additional transaction authorization method is required on top of the existing process. For example, a one-time password is sent via SMS. The user must authorize the transaction twice, but only for a limited period. It will significantly raise the bar for attackers and be troublesome for users, but only for a short period of time.  

Device identification 

If there were a reliable source of information that could associate a device ID (like IMEI or other unique ID) with the user’s name, then banks or fintech could use such a database to verify:  

• phone owner,  
• history, whether the phone is associated with multiple users and banks,  
• recent SIM duplication,  
• lost/stolen status, etc. 

It seems like a good idea, but unfortunately, it requires a current and available database for all PSPs (payment service providers). Currently, we don’t have one, but as a part of PSD3, there will be mandatory payee verification that will require building a database associating users with account numbers. If, in the future, this database is expanded to include phone IDs, it could be utilized for our purposes.  

Device fingerprinting 

An application running on the phone can check if the phone is rooted or jailbroken, if it’s running in an emulator, or if it shows other signs of tampering. These techniques are often used by attackers because they automate attack flows. Anti-tampering checks can be easily implemented by using ready-made libraries – we have such a solution for the iOS platform. 

Additionally, the PSP system can verify the IP address of the device and its network origin. For example, if the device is not initialized from a completely different location than where it was last seen before the recovery process. 

Both the above ideas – device identification and fingerprinting – may be used as an additional feed of essential data for fraud detection or behavioral analysis systems. 

Opt-in recovery 

The pairing of a new phone is disallowed by default. When the user wants to pair a new device, they must unblock this operation via a more trusted channel – e.g., a call center or IVR. 

This idea is disputable and heavily dependent on the existence of trusted channels and their immunity to social engineering, but it could be utilized in specific usage scenarios. 

More configurable security options 

Most of the above ideas somehow weaken the usability of the payment application. However, security has its price, and the user should understand that it’s impossible to have a system that’s both highly secure and very comfortable. On the other hand – users have different needs. Perhaps we should consider giving the user the option to configure the app: do they prefer a more comfortable or more secure experience? It could be implemented as a simple selection of a “security/comfort” level or, for more advanced users, as picking authentication and authorization methods, enabling stricter fraud detection, etc. If properly implemented and explained, such an approach will educate users and give them more impact and responsibility for their security. 

Of course, even the most comfortable level of security controls should still be in line with compliance rules. More about current compliance efforts in the next article in this series. 

The purse and safe approach / More protected subaccount 

The idea is to divide the user’s account into two parts – the “safe” and the “purse.” All income is credited to the “safe” account. Everyday expenses are debited from the “purse” account. The purse account is easy to use – it offers lower security options, but on this account, the user has a relatively small amount of money. The “safe” account could be debited only for moving money to the “purse,” and this operation should be protected by a strong and possibly less convenient authorization method. 

Such an organization of user accounts is convenient for everyday use and more secure for most users’ financial transactions. It’s also relatively easy to implement using functionalities that are already present in most banking and fintech apps – such as subaccounts, savings accounts, or even overnight deposit models. 

Last but not least, this idea will be familiar to users because it resembles their usage habits for physical cash.  

E-commerce systems are a crucial component of the overall payment ecosystem. Attackers often use e-commerce or e-marketplaces to target victims and launch phishing attempts. Below are some questions to consider that could help e-commerce owners to protect their customers: 

• Do you need a user-to-user chat? Such a communication channel is often used by attackers to initiate attacks and phishing attempts. 
• If so, do you need to send URLs in those chats? Propper filtering and disabling URL sending should significantly hinder phishing attempts. 
• Do you protect and educate first-time users? Typically, attackers target users who are first-time users and are unfamiliar with how your platform works. Do you educate new users about transaction flow, security options, and typical fraud scenarios? Maybe a good option is to consider limited functionality for new users by default. 
• Do you pay proper attention to payment provider integration? Especially the security of payment plugins, proper integration with your system, and additional options for transaction integrity protection – from checkout through payment processing to order fulfillment. 

Summary 

Security teams are constantly developing new and secure processes, while attackers are constantly adapting, and there is no one-size-fits-all solution to protect electronic transactions. Compliance efforts are going in the right direction, but they will always lag behind the moves of attackers. Moreover, current financial systems are becoming more complex, which creates new and unexpected technical vulnerabilities.

That’s why we need to have multiple options for protecting financial apps. The “raise the bar” approach means using carefully chosen protections – layered, tested, and tuned to real threats. Fraudsters experiment, adapt and measure what works. We must do the same. I hope this article helps you find solutions that fit your business, users, and current threat landscape. Let’s raise the bar together. 

Want to review your transaction flows, fraud detection, or mobile security setup?  

We’ve worked with banks and fintechs for over two decades – not just testing but helping teams rethink what “secure” really means. We’re happy to share what works, what doesn’t, and where attackers still get through. We may have seen a lot, but we still raise the bar with every test. 

Acknowledgments 

To our Securing team – for finding vulnerabilities worth writing about and pushing systems far beyond their default capabilities. You’re the reason we know where the real risks hide. 

To OWASP Global AppSec EU community – for every conversation, every scenario, every idea that turned into a better question or a smarter answer. 

To the Confidence Conference community – for providing me with a space to discuss transaction authorization pitfalls in front of a crowd that always asks the right questions. 

Wojciech Dworakowski Managing Partner