Mobile Payment Risks and Security
Table of Contents
1 Executive Summary
2 What are Mobile Payments?
2.2 Proximity mobile payments
2.3 Remote mobile payments
2.4 Mobile Payments Growth
3 Popular Mobile Payment Applications Overview
3.1 Google Wallet Overview
3.1.1 Google Wallet Security Analysis
3.1.2 Google Wallet Reported Vulnerabilities
3.2 Apple Pay Overview
3.2.1 Apple Pay Security Analysis
3.2.2 Apple Pay Reported Vulnerabilities
4 Mobile Payment Industry Risk and Security Concerns
4.1 Mobile Payment Risks
4.2 Mobile Application Risks
4.3 Strategies to Address Risks
Mobile payments are quickly becoming ubiquitous, from developing nations in Africa to Europe and the United States. In the United States alone the mobile payments industry will grow by over $400 billion from 2014 to 2018, representing an incredible 600 percent growth. In that same time frame, United States mobile payments done at brick and mortar stores will grow by over $180 billion.
With growth comes risk. As more and more mobile device users use their device to make payments using an ever increasing number of applications and websites, it increases the attack surface. The end user is not the only set of attack vectors, merchants are also at risk. Merchants use mobile-point-of-sale (mPOS), point of sale and other systems and communication to authenticate, authorize and complete a transaction. Banks, communication providers, and payment processor services are also often required to complete the payment transaction. With such a large number of assets and stakeholders involved in order to make a single mobile payment succeed, it provides malicious actors with a target rich environment.
There are three main mobile payment methods: mPOS, proximity mobile payments, and remote mobile payments. Each of these payment methods have a multitude of technologies, configurations, assets and stakeholders. This creates an almost limitless number of permutations, further muddying the security posture of any single implementation.
Google Android and Apple iOS devices account for most of the mobile industry. They both have their own mobile payment applications, Google Wallet released in 2011 and Apple Pay released in September 2014. Both use near field communication (NFC) technology to execute mobile payments, but beyond that they differ in their implementation styles. Security analysis of both products reveals various potential security risks, highlighting the fact that even the largest enterprises’ mobile payment solutions are not a guarantee to consumers of mobile payments being risk-free.
The mobile payment ecosystem has specific risks, such as: identify theft, information disclosure, repudiation, replay attacks, authentication, consumer obsolete technology, transaction fraud, and denial of service. The vulnerability and threat for each risk is summarized, as well as proposed countermeasures.
The mobile payment risks are a subset of the mobile device risk attack vectors. It is therefore important to understand the difference. The Open Web Application Security Project (OWASP) provides a top 10 mobile security risk list and should be part of an overall security solution.
Mobile applications, such as Google Wallet and Apple Pay, can have very specific risks as well and those need to be considered as part of the overall mobile security for development, acceptance testing, application examination process, and security software to run on the device itself. A top 10 list of mobile application risks is summarized with a brief discussion on each as to its importance.
An overall strategy to mitigate mobile payment risk is to map out the threat landscape on the mobile payment ecosystem and then implement a detailed test plan. Proper development of the test policies and procedures is vital to proper risk mitigation by all major stakeholders. It is equally important that there be security collaboration between stakeholders, such as banks and payment processor services. Proper data classification is another strategy to mitigate risk. A number of reported vulnerabilities found show proper data classification was not done. The overall security plan should include data classification policies and procedures. With proper data classification an encryption strategy should be applied to data-at-rest, data-in-transit, and data-in-memory or process using FIPS 140-2 cryptography compliance. Finally, levels of redundancy to increase security is a strategy that should be done by applying layers of security with each layer including proper data classification and encryption.