Payment transaction authentication methods. Which is the best?

News & Publications > Blog

Posted on 07.09.2021 at 15:22

Regular user authentication methods such as portals, enterprise systems, VPNs, and so on are familiar to us all. We all know about authentication factors (what you know, what you have, and what you are), two-factor authentication, multi-factor authentication, how to implement these factors, and much more besides.

In relation to payment transactions, there are many hidden pitfalls, because there is a range of fundamental differences between a regular application (in an enterprise, for example) and a payment system (like a plastic card, e-wallet, etc.)

Let’s take a look at this in more detail.

With regard to enterprise-level authentication, we can find many tried-and-tested solutions for solving the issue: protocols (like Active Directory, SAML, RADIUS, OpenID, OAuth, a set of RFCs, or a set of ISO standards), specifications, the vendor’s software and hardware for facilitating authentication providers, as well as software and hardware that can communicate with these providers. Another topic for discussion is client authentication devices, such as tokens, MAC calculators, smart cards, NFC rings, fingerprint scanners, and so on.

This huge market always tries to remain organized and to create solutions that are intercompatible. This is excellent, because you can get an enterprise-level application (for example, an e-doc system) and link it with your users’ directory via Identity Management (IdM) and with various authentication methods via a Single Sign-On (SSO) system. The SSO system will cover your authentication requirements, while the IDM will manage users and authentication factors. It doesn’t matter which vendor provides these components for you. All of them will work together with standardized protocols.

The matter of a payment infrastructure, however, is much more complex. I see two major reasons for this. The first one is that user management is entirely different from regular applications. The second is that no standards exist for authenticating a user or a user’s transaction via payment transaction processing. As a result, each financial company (bank, fin-tech, e-wallet, investing platform, etc.) has to invent something based on its own vision and its own risks.

Let’s imagine that you’re a regular bank. If we gloss over features like Open API, then you provide two major options to a user for spending his or her money: using a payment card and via a remote banking system (mobile banking, online banking, etc.).

In terms of offline payments using a card, there are no issues. You work with POS terminals via a payment system like Visa or Mastercard. The payment process is completely transparent and secure.

With a card-not-present transaction (e-commerce), then according to Verified-By-Visa requirements (and those of similar services), you, as the card issuer, must authenticate the cardholder. Authentication takes place.

The transaction will be processed by specialized infrastructure and software: card processing. Usually, this is a separate division in a bank with its own rules that are combination of payment system requirements (like those of Visa) and internal risk management. These rules, infrastructure, and software provide a highly limited range of transaction authentication mechanisms. Usually, one of the following is used: the card’s PIN, a separate, static PIN, a one-time password (OTP) via SMS, or a one-time password via a push notification.

Can you manage authentication methods? No. Can you use something better and more secure than SMS? No. Can you ask a processing vendor to cover your requirements? Yes, but be ready to pay. Without any guarantees. Compare this with enterprise applications, and you’ll see the difference.

You might ask yourself: do I really need to change anything? Maybe things are OK as they are? Let’s see.

Using a card’s PIN to authenticate a payment transaction over the internet is not a good idea. It can be highjacked at many points on its path from the user to where it’s processed. There are many tools and techniques for doing so: keyloggers, man-in-the-middle attacks, man-in-the-browser attacks, trojans, exploits, and so on. I don’t think there is any need to explain why card PIN theft is a bad thing.

A separate, static PIN has the same vulnerabilities, but at least the card’s PIN won’t be stolen and the card won’t be used offline by the perpetrator.

The disadvantages of an OTP via SMS has been discussed many times. It is not secure at all: it has a huge number of technical and technological vulnerabilities and can be highjacked using social engineering, phishing, etc. In addition, it is extremely expensive. And what’s more, its use is becoming prohibited in more and more countries because of its disadvantages.

An OTP via a push notification has the same disadvantages from a technical and technological point of view. It is cheap, however.

Moving forward, you have several options for building your remote banking system.

Option one is to build it around card processing. In this case, you will have all the authentication (e.g. security and maintenance) problems from the previous paragraphs. You will become hostage to slow, very exclusive, and expensive processing vendors, to the rules of payment systems like Visa/Mastercard, and so on. Forget about modern, convenient services.

Option two is to build a remote banking system to your own specification. Using modern techniques, this can be a set of back-end services and a front-end solution. In this case, you can set up the transaction processing flow however you want, with transaction authentication that follows your own rules. Of course, you can find solutions like this from trusted vendors. If a vendor’s or your own internal solution will allow, you can integrate IdM and SSO within your remote banking system and additional services.

I believe that if you could choose a payment transaction authentication method, you wouldn’t choose a non-secured, expensive method with many known issues, like SMS messages or a static PIN.

From my point of view, the best solution for payment transactions is to use mobile-centric confirmation solutions, like PayConfirm. It has a very high level of security, is cheaper than SMS messages, and is much more convenient for users.

If we continue to imagine that you are a bank, you might, of course, prefer to combine transaction authentication methods for card-not-present transactions and for a remote banking system. Yes, you can take the easiest route and make all of your systems as bad as the worst component thereof (card processing, for example). Another way, however, is to push processing vendors to support your requirements. It may be that requests like this will dictate authentication standards, as in the enterprise sector. This will be good for all participants therein: financial institutions, security vendors, end users, support companies, etc.

Thus, a bank’s position is not a very convenient one in terms of payment transaction authentication. But fintech, e-wallets, and other financial institutions do not have the same restrictions as a bank. This means that they can use modern mobile-centric solutions, which are cost-effective, secure, and convenient for end users.

 

DR. PAVEL MELNICHENKO, Chief Technology Officer, AIROME Technologies

Pavel Melnichenko is an international technology inventor with a focus on cybersecurity. He is the Co-Founder and main solution architect of Airome Technologies, based in Singapore.

Pavel has a university degree in Complex Security and Computing, Ph.D. in Engineering Science and more than 10 years of experience in cybersecurity and solution architecting. His work experience and highly scientific expertise varies from cryptographic and authentication solutions development to governmental level projects architecting.