Mobile payments security. What should developers know about it?

How secure are payment services?

While the digital payments market is growing in some countries, local governments are pushing to get rid of cash. It is time to start thinking about the security of digital payments. Everyone is happy to pay with their credit card or use mobile payment services like Apple or Google Pay, but how secure are payment services? Another concern of contactless payments is a fear of the possibility of man-in-the-middle attacks (MITM - attacks when traffic is intercepted and re-configured).

Moreover, almost every day we can hear a new bank opening their API for third-party developers. This fact lures many developers to integrate it into their applications, usually leaving parts of the system unprotected. Sad but true, without having a solid knowledge in the area of secure payment solutions it is almost impossible to develop a secure mobile application that interacts with a digital wallet.

Let’s dive into how our digital wallets on mobiles can be secured and what are the recommendations for the security of mobile payments. Before considering interaction with user money on a mobile, it is important to understand that comparing to server-side solutions, an attacker may have full access to the device and is able to substitute any (software or hardware) part of the mobile ecosystem. This increases the chances of mobile payment security being compromised when making the transaction via contactless gateways or sending a request to a payment server.

Knowing vectors of attacks, we propose to break down mobile payment transaction problems to solve into smaller parts:

  • Secretly store sensitive information locally.
  • Pass transaction data to the payment gateway.
  • Prove identity of payer and payee.

It’s true that there is a lot of work ahead, but vital. Because the mobile application is involved in every part of the transaction, it shares responsibility for payment security. Namely for securing stored information (data-at-rest), securely passing the data to the receiver (data-in-transit) and has to prove it’s identity. Additionally, all the above-mentioned data should be impersonalized as much as possible due to legal requirements (e.g. GDPR)

Therefore, let’s take a closer look at what we can do.

mobile payment, security, mobile payment security, mobile app, financial app, iOS, Android, mobile development

Secure payment services. A few tips from developers for developers.

The mobile application may store user sensitive information in temporary and/or permanent memory.

First, when using temporary memory it is important to do a cleanup right after this data has been processed. Unfortunately, many systems just mark memory as free for re-use but do not do actual cleanup (e.g. it is not so easy to erase string data). Also, due to the wrong scope definition, data may not be garbage collected on time. A quick peek into what is going on can be done using tools like AIDA.

What about permanent storage?

As this data is available for a longer period of time and survives app termination, it is important to apply the proper level of encryption and make sure that storage is safe. Each OS (iOS, Android) has its own implementation of such storage. Additionally, there are encrypted versions of local database implementations (e.g. Realm, Room (original implementation provided by Google is not safe), etc.).

Looks easy, just save keychain on iOS and choose MODE_PRIVATE modifier for preferences on Android.

Relying only on the security provided out-of-box by iOS/Android is called black box security. Blackbox approach assumes that the attacker does not have access to the victim’s device and the device itself is not running any type of malware. Unfortunately, it is not always true, the attacker may have access to the victim’s device usually by running viruses (malware applications) or having physical access (So having jailbroken iOS device or rooted Android device it is possible to compromise the security of the targeted device.).

So to ensure an even higher standard of mobile security, it is recommended to apply an extra layer of encryption made by the application. Wide-known methods of encryption are AES algorithm used for symmetric encryption / decryption and RSA public-key algorithms. For one-way verification encryption, a one-way hashing algorithm like SHA-1 can be used. Now it is better, but the encryption algorithm requires a key, so we still need to somehow hide it. One way to achieve the desired effect is the permutations of code and key value. This approach is usually called white box as it assumes that the app is running in an environment where an attacker controls everything (so-called total control).

When data is safely stored on the device, the completed transaction mobile app has to pass data to the payment gateway. Passing data to the payment gateway is not different from storing data, i.e. it is highly recommended to implement an additional level of security on top of communication protocol.

Additionally, communication between the mobile app and gateway is vulnerable to middle attacks, so the mobile application has to check if the gateway is not compromised too (e.g. using certificate pinning). From the mobile side, to prevent attacks when data is repeated (so-called replay attacks), it is recommended to send some unique data (fingerprint) that expires after the response is received. To protect data from being appended by extra data, it is worth looking for implementing integrity check (e.g. CBC).

And finally, to avoid leakage of code logic, it is recommended using code obfuscators. To protect itself on runtime, it is possible to check the integrity of mobile OS and try to detect if the device is debugged.

The security team is what you need when developing mobile payment solutions

During development, it is hard to achieve the best quality of UI/UX, code scalability and security (this is not a full list). Moreover, mobile security is usually a challenge even for an experienced developer. These facts bring security teams to the stage, teams with the primary focus on security and are not involved in the development of the reviewed application. Using such teams helps to eliminate security concerns and discover security issues before they creep into production.

See our blog post Are you creating a mobile app or a mobile version of your digital product?

Consider bug bounty program

It is also recommended to dedicate part of your budget for bug bounty program as it is one of the ways to discover bugs in the production environment and help prevent any types of exploits.

FM work for the financial industry

At FM we have an experienced team of native mobile developers who take care of each aspect of the mobile payment solution you are building (or want to build). If you want to know more, call us or drop us a line!

P.S. Watch a demo video of a mobile product we created for the financial industry!

Read also

Most Read

1 What is a legacy system, and why do companies keep using them?
2 Mobile payments security. What should developers know about it?
3 How to fold QA into every sprint
4 Software development view of healthcare wearables
5 How to quickly add a date dimension to a Pentaho Mondrian OLAP cube
6 Nearby Messages: Sharing Information With The Person That Is Near You
7 Creating a digital product for the healthcare industry?
8 7 reasons to use real time data streaming and Flink for your IoT project
9 How to create an effective Asset Tracking System?
10 Minimum Viable Product (MVP) in software development - what it is and how to define it. Product Owner and Project Manager perspective.

Digital products from concept to launch

We understand that creating a product is a challenging and risky endeavor and believe that having a partner with experience and know-how is a critical first step.

Learn More

The Digital Product Journey

From idea to launch we guide you through the startup experience

Learn More
Path Created with Sketch.

Before you head out, you can download our latest E-book “18 Software Product Killers Every HealthTech Strategist Needs to Know (part 1)”

Yes, we know it's a mouthful, we're working on it. Enjoy!