Mobile Payment Risks and Security

Mobile Payment Risks and Security

Source: http://en.wikipedia.org/wiki/Mobile_payment#mediaviewer/File:Mobile_payment_01.jpg

Prepared By:

Glenn Ford

Table of Contents

1    Executive Summary  

2    What are Mobile Payments?  

2.1    Mobile-point-of-sale  

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  

5    Conclusion  

6    References

1. Executive Summary

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.

2. What are Mobile Payments?

Mobile payment is defined as, “Payment for products or services between two parties for which a mobile device, such as a mobile phone, plays a key role in the realization of the payment” (ISACA, 2011). The internet has changed the way business is done and the average person’s life in how we communicate and work. Mobile devices have had just as large an impact as the internet on businesses and individuals. Mobile phones are ubiquitous, allowing anyone to access the internet and execute a financial transaction. A mobile user now has the ability to do many types of financial transactions from scanning their paychecks to have them deposited to waving their phone in front of devices at a restaurant to buy a hamburger. In developing nations, the number of mobile users outnumber the number of users with bank accounts (Porteous, 2006) creating an incredible opportunity to expand financial activity in those nations.

In order to better understand mobile payment security and risks, it is important to first understand how mobile payments work and the adoptance rate. Most mobile payment capabilities are accomplished in one of three main ways: mobile-point-of-sale (mPOS), proximity mobile payments, and remote mobile payments.

1. Mobile-point-of-sale

Mobile-point-of-sale systems allow merchants or businesses to accept card payments using a mobile device, such as a smartphone or tablet. This is usually accomplished with a mobile application that acts as an electronic cash register interface and a hardware device attached to the mobile device. Combined they create an mPOS that any size business or merchant can use to provide transactions anywhere in the world where there is connectivity to the internet (Ray, 2014).

2. Proximity mobile payments

Proximity mobile payments is the fastest growing sector for mobile payments (Carrington, 2013) and allows mobile users to pay at a venue such as in-store, airport, or directly from marketing advertisements. The most popular type of proximity technology is near field communication (NFC) which has a range of approximately 4 inches. NFC allows a mobile user to tap their NFC-enabled device to a compliant merchant/business device to make a payment. QR-codes are another way to make proximity payments. With QR-code enabled mobile application, the user scans a QR-code provided by the merchant or business which is then reconciled at check-out within the mobile payment application (Ray, 2014).

3. Remote mobile payments

There are two main types of remote mobile payments. Peer-to-peer (P2P) and a mobile application/website. P2P uses the mobile phone as a proxy and sends payment person to person or person to business. The transaction is often done as a text but is also done in a mobile application. Mobile application or website is usually done in one of three ways:

1. Card - User makes a purchase in a mobile app or website using their existing card.
2. Wallet - User makes a purchase in a mobile app or website with an electronic wallet that encapsulates their card information.
3. Direct Carrier Billing - User pays directly to their mobile subscription and is an alternative method of payment to using a credit card or debit card (Ray, 2014).

4. Mobile Payments Growth

As illustrated in Figure 1 below, mobile payments has an incredible growth trajectory. According to Nichols, with data provided from BI Intelligence, the United States mobile payments industry will grow dramatically to over $400 billion in just 4 years. In that same time frame, United States mobile payments done at brick and mortar stores will grow by over $180 billion (Nichols, 2014). This does not go unnoticed by cybercriminals and other malicious actors. With the huge projected growth comes an increase in the attack surface and thus it is important to understand the associated risks to consumers and businesses.

Figure 1 - Mobile Payments Growth for in-store and mobile commerce. (Nichols, 2014)

3. Popular Mobile Payment Applications Overview

The competition to be a leader in the United States soaring mobile payments industry is being led by a few in the mobile market:

• Google, who is the developer of the Android operating system released Google Wallet in 2011,
• Apple who released iOS8 on September 17th, 2014 and their new flagship phones iPhone 6 and 6 Plus on September 19th have introduced a game changer with their Apple Pay mobile payment system,
• Square was launched in 2010 with their first application and do financial services, merchant services aggregator and mobile payments,
• PayPal was founded in 2000 and as early as 2004 supported SMS mobile payments and QR codes or PayPal Beacon in 2013,
• And Level Up launched in the first quarter of 2011 and uses QR codes for its mobile payment systems.

A security analysis of the technology giants products’ Google Wallet and Apple Pay are discussed below to provide a better understanding of the risks to consumers, merchants and payment processor services.

1. Google Wallet Overview

Google Wallet is a mobile payment system that allows users to store card information digitally on their phone. A user of Google Wallet, using NFC technology, can make a payment by tapping their phone against a MasterCard PayPass or Visa payWave system. Google Wallet can also receive discounts or advertisements from the merchant as part of the transaction. Once NFC communication has been initiated, the owner of the Google Wallet must enter their PIN number to provide authentication and authorization of payment. Google is constantly working to add more merchants and capabilities such as storing airplane boarding passes, tickets, ID, and keys (von Behren, 2011).

1. Google Wallet Security Analysis

Google Wallet is a NFC mobile payment application. It requires the merchant to have a Point of sale (PoS) device that receives the customer’s information to complete the transaction. In order for this to work, Wallet stores the credit card number, card holder’s name, and expiration date on the phone. Google wallet is based upon the Android OS, which is open source. These two architectural avenues are attack vectors. The customers’ mobile devices become targets, specifically the Wallet application. The second major area is the fact Android is an open source system creating yet another threat vector as it’s a white box software environment allowing hackers to study every line of code looking for an exploit (Ba, 2013).

    NFC technology is also a threat vector. An attacker can place a receiver to intercept transmissions and perform eavesdropping. Attackers could also perform a Man-in-the-middle (MITM) and actually change the data by transmitting data at certain frequencies at certain times (Haselsteiner and Breitfuß, 2006). NFC chips on mobile devices is also another attack vector, although Google added an encryption chip called a “secure element” to remediate this threat. Wallet also does not work with the NFC chip when the phone screen is locked, thus adding additional security.

Android devices can be “rooted”, giving the mobile owner privileged access. This causes security threats to Wallet for both access to the PIN number which is stored in the application, SQLite tables with unencrypted data about the card, brute force attacks on the PIN, and access to pre-paid cards by resetting Wallet and picking a new PIN. Wallet allows merchants to send marketing material. This is another attack vector as it provides a mechanism to do phishing or malware drive-by download attacks that target marketing landing pages (Ba, 2013).

Both the confidentiality and integrity of Google Wallet have threat vectors. The same is true for availability by using Distributed Denial of Service (DDoS) attacks on the mobile payment system(s) and/or merchant payment systems.

2. Google Wallet Reported Vulnerabilities

Below is a summary of the known vulnerabilities that have been reported for Google Wallet:

• ViaForensics was able to access the Cardholder name, last 4 digits of the credit card, and expiration date if the phone has been rooted. This is even true if Google Wallet has been reset. Google announced Wallet is not supported on rooted devices but has since taken steps to protect this data (Golany, 2012).
• Prepaid cards for Google Wallet were exposed when Google Wallet was wiped and when setup again to a new account all prepaid cards were accessible. This has since been fixed by Google (Golany, 2012).
• Research Joshua Rubin with Zvelo successfully did brute force attacks on the PIN number (4 digit) of Google Wallet. Rubin also was able to retrieve the PIN on rooted devices (Golany, 2012).
• Trend Micro examined and discovered that Google contains a vulnerability that can be exploited for phishing attacks using Google SDK. The versions analyzed were Google IAP versions 2 and 3 (Sun, 2014).

2. Apple Pay Overview

As with Google Wallet, Applet Pay uses touch-less NFC technology. Once Apple Pay is launched the user would tap their mobile device on the NFC reader. This initiates a request for NFC connection and once the device is securely connected to the payments system it selects a credit card to use. The unique quality of Apple pay is that it does not store the card information on the device, rather it uses a device specific account number. The account number is stored on a dedicated chip on the iPhone called a secure element (SE) and is only valid if used from that device. This number is never stored on any Apple server or shared with any other process events. This number must be combined with a dynamic secure transaction code and another layer of security using the fingerprint scanner. For older iPhones the user can use a PIN number to complete the authentication and authorization process. This transaction information is sent to the merchant who sends it to the acquiring bank who validates the information for the requesting merchant. Then the information is sent from the bank to the payment processing network, e.g. Visa or MasterCard. Once the payment processor has received the information from the bank it can determine account information, such as a credit card, and also assurance the transaction security code is valid. Apple has no record of which credit card is being used or how. Only the payment processor does (Cherrington and Day, 2014).

1. Apple Pay Security Analysis

NFC MITM are most likely no longer an attack vector as the hacker only has the potential to access the device account number combined with the dynamic security code. This makes it highly improbable that this could be used for malicious intent.

The device account number is paired with the device itself so even if this 16 digit token is stolen it cannot be used without the device also.

Card skimming is eliminated by the dynamic architecture of NFC and memory scraping malware such as Dexter is not a threat because there is no PII or credit card information ever transmitted or stored on the device.

Recent attacks on companies such as Target and Home Depot would never have happened if using Apple Pay. This is because the only information the merchants may store, if even that, are the dynamic transaction security codes which are only usable once.

A rather simple attack vector is combing physical and biometric cracking. Apple Pay uses fingerprint biometrics for user authentication, which has been shown to be easily breakable (Chaos Computer Club, 2011). If the user’s phone is stolen, it would not be hard to break the biometrics, which unlocks the entire phone and financial payment process.

Another potential attack vector is when the credit card information is initially entered into passbook, which uses the phone’s camera. If the phone is already infected with memory malware or other malware that has compromised the camera or passbook the information can be stolen.

A recent bug in iOS allows an attacker to replace a legitimate application with a clone developed by the attacker (Xue, 2014), enabling a MITM attack. The attacker could masquerade passbook and steal card information.

The last attack vector to be discussed for Apple Pay is the payment structure themselves. From the initial description of Apple Pay the unique one time transaction data makes the only mass exfiltration point the payment processors. If the likes of Visa or MasterCard are hacked the user’s card is compromised (Cherrington and Day, 2014). Apple has done an excellent job of making mobile payment secure by having no centralized repository on their servers, unlike Google, and no card information passed along at any point during the transaction. Which again, Google Wallet does not have these layers of security.

2. Apple Pay Reported Vulnerabilities

Apple Pay was launched September 19th and no reported vulnerabilities have been made as of yet.

4. Mobile Payment Industry Risk and Security Concerns

The previous section focused on specific vendor products and services. This section takes a macro level perspective at the mobile payment industry with a central focus on NFC enabled payments.

The number of various stakeholders, assets, technologies and implementations used creates an endless number of permutations, which in turn increases the number of risks. The complex mobile payment environment creates an extremely difficult task to creating a good security posture. To put this in perspective, assume the combination of our possible assets and stakeholders is equal to 52, the same number as a standard deck of cards. 52 “cards” has approximately 8.0658e67 permutations. This is more than 4 billion years represented in seconds (“52 Factorial”, n.d.). Trying to eliminate all possible risks for all 52 factorial (52!) implementations is never going to be 100% possible. Figure 2 can help visually conceptualize the connections required to complete a mobile payment with today’s current technology.

Figure 2 – Visual conceptualization of mobile payments system connections (Webster, 2012).

There are two categories of technology used for consumer endpoint devices making a mobile payment: proximity payment and remote payment (ISACA, 2011). The technologies used and geographical adoption for each payment category are:

• Proximity payment is normally done over the air and uses NFC technology enabling the mobile device to become a contactless payment card. There is also an alignment with trusted computed media such as subscriber identity module (SIM) or trusted platform module (TPM). NFC based mobile payments are being used in Europe, North America, and Japan. Developing nations are just beginning to adopt NFC.
• Remote payment is performed anytime the mobile device uses a browser or application to authenticate and authorize personal information that is stored in another location. There are a number of technologies for this, such as: wireless application protocol (WAP), short messaging service (SMS), unstructured supplementary service data (USSD), and mobile subscriber identification number (MSIDN). Some of the older technologies such as SMS and USSD are very popular in developing nations of Africa, the Middle East and areas with very little banking penetration.

The rest of this section will focus on the risk to mobile payment, mobile application risks and finally strategies on how to address risks.

1. Mobile Payment Risks

Mobile payment risks involve 3 main participants and their role in the mobile environment: (1) The user; (2) The network or communications provider such as the mobile network operator; and (3) The payment service provider. ISACA described some of the main mobile payment risks with associated threats, vulnerabilities, and possible countermeasures (ISACA, 2011, p. 11).

• Identify theft, information disclosure and replay attacks - These risks target the user and the vulnerability is over the air (OTA) between the mobile device and the PoS with the threat being interception of communications traffic. Possible countermeasures are TPM, encryption, and secure protocols.
• Authentication information disclosure and repudiation - These risks target the user and the threat is interception of authentication data caused by a vulnerability if a user downloaded a malicious application. Possible countermeasures are authentication of user (PIN, biometrics, etc.), digital signatures on all applications downloaded, and TPM.
• Lack of adopting technology - Often times setting up and configuring a new phone is very complex (threat) for a user when changing or replacing a mobile device with a new one (vulnerability). This can be remediated by simplified user interfaces and have a trusted 3rd party setup the security values for the TPM.
• Transaction fraud and provider liability - The threat of user masquerading greatly increases if the lack of multi-factor authentication exists (vulnerability). Possible countermeasures are to enforce multi-factor authentication.
• Data and privacy disclosure, user profiling - The threat to the user of malware on the mobile device or poor data control at the merchant processor or payment processor can often be caused by vulnerabilities in the mobile device internet and geolocation capabilities. Possible remediation are allowing the user to control this data.
• Denial of Service - The threat to a service provider exists if their PoS is flooded with fake requests. The vulnerability is the fact PoS accept OTA communications. A possible countermeasure would be to provide request filtering by the NFC reader. However, this could still be flooded to overwhelm the request filtering.
• Theft of Service, replay or message data integrity - These risks can be caused by the threat of masqueraded attacks or actual tampering of the PoS and the vulnerability is the fact the PoS devices are installed at merchant locations making them an easy target. Possible countermeasures are vetting of PoS vendor(s), authentication techniques of messages, and vetting of authentication and accounting.
• Theft of content, digital piracy, provider digital rights infringement, revenue loss - The threat to the service provider exists if the user of a mobile device illegally distributes content. This threat can exist due to a mobile device vulnerability of not having proper digital rights management (DRM). This can be remediated by implemented DRM in the TPM design with proper DRM encryption.
• Theft of service or content, loss of revenue, illegal funds transactions - The service provider is at risk from the threats of message modification, transaction replay, and fraud control evasion. These threats can exist from vulnerabilities such as the weak encryption of GSM and SMS sent as clear text. Possible countermeasures are industry standard secure protocols, SMS message authentication controls and encryption.

The Open Web Application Security Project (OWASP) provides a top 10 mobile security risk list and much of it overlaps with the previous mobile payment specific risks already discussed. The top 10 2014 list defined by OWASP are: (1) Weak Server Side Controls; (2) Insecure Data Storage; (3) Insufficient Transport Layer Protection; (4) Unintended Data Leakage; (5) Poor Authorization and Authentication; (6) Broken Cryptography; (7) Client Side Injection; (8) Security Decisions Via Untrusted Inputs; (9) Improper Session Handling; (10) Lack of Binary Protections ("OWASP Mobile Security Project”, 2014). It is important to consider risks from multiple sources and to perform risk assessment and management for the entire ecosystem, not just mobile payments as other systems or processes could be exploited.

2. Mobile Application Risks

    It is important to look at mobile device applications as a possible attack vector. All modern mobile payment systems such as Google Wallet, Apple Pay, and banks use an application to do transactions, not the mobile device browser. Many offer a mobile website that can be accessed from mobile browsers, which are also in of themselves an application. Not all users will use the native browser, introducing a 3rd party browser into the mobile application risk spectrum. The list of mobile application risks should be used as part of the overall mobile security for development, acceptance testing, application examination process, and security software to run on the device itself. Below is a list of the top 10 mobile application security risks (Pollock, n.d.):

1. Activity Monitoring - Some of the attack vectors related to activity monitor are SMS, email, audio eavesdropping, video eavesdropping, location data, contact lists, call history, browser history, input of data, and data files.
2. Unauthorized dialing, SMS and payments - Compromised phones could make unauthorized payments, use the phone for premium call and SMS text rates, or use SMS as a vector for worms to infect others.
3. Unauthorized network connectivity - Most malicious software wants to exfiltrate information and mobile devices are inherently designed to communicate. Attackers could exfiltrate from your phone a number of ways, such as: email, SMS, HTTP, TCP, UDP, Bluetooth, and DNS exfiltration.
4. Masquerade of User Interface - A form of phishing, a malicious application could impersonate as a bank in a MITM attack. If successful, the user will authenticate through the impersonated UI and send credentials to the attacker. PayPal and Wells Fargo are classic examples of popular targets for this (Westervelt, 2014). The iOS exploitable bug discussed earlier falls into this risk category.
5. System Modification - Attackers want to hide their presence and this is often done with a rootkit or an access point name (APN) proxy. Once accomplished many of the other attack risks become a lot easier to accomplish undetected.
6. Logic or Time Bomb - If a 3rd party application is installed with or without the users’ knowledge, it could trigger backdoors based upon users’ specific usage, or an event or specific time.
7. Sensitive Data Leakage - Attackers could access sensitive data using side channels or through some inadvertent action performed by the user, including authorization information and PII.
8. Insecure Data at Rest - Many mobile applications store sensitive information and this data must be properly encrypted while at rest or an attacker may be able to intercept the data. Same is true for data in memory and data in process but must be unencrypted for the application to use the data, so proper containerization of the application must be performed.
9. Insecure Data in Transit - Proper encryption methods must be used, such as SSL. However, on mobile devices it is possible to downgrade HTTPS to HTTP and applications must be aware of this and also properly handling failure of certificates to avoid MITM attacks.
10. Hardcoded Password Key - This is a technique developers often use as a shortcut which makes implementation, debugging and support easier. Care must be given to properly vet the application to avoid this risk by performing manual code reviews and automated source code analyzers.

3. Strategies to Address Risks

All mobile payments should have a thorough testing plan. Morrow described a complex security landscape for mobile payments and the importance of implementing testing policies and procedures. He summarized the threat landscape and how those threats impact the testing process to make sure it will address data-in-transit (DIT), end-to-end payments and other mobile payment system configurations (Morrow, 2014). Morrow’s work makes strong arguments on why proper testing must be done to mitigate risks for mobile devices, which will strengthen the security of the mobile payment ecosystem. The test policies and procedures should, at the very least, include the top risks listed in this paper for mobile payment systems, mobile device, and mobile applications.

Mobile payments have more risk than many other mobile processes due to the fact several parties are involved to execute and complete a payment process. This problem can be magnified if services are outsourced without clearly defined lines of accountability and governance. Due to the many parties involved, it opens more avenues for attackers to exploit, both technical and socially engineered (ISACA, 2011). Careful planning and testing must be performed by all parties involved based upon the technologies and processes used.

The use of multi-factor authentication would provide better user identity protection for the mobile device user and assurance for the merchant and payment processors. For mobile payments using NFC protection can be increased using dynamic card verification values (CVVs) (ISACA, 2011). This protects against forged devices as it will present the wrong CVV as described during the Apple Pay security analysis.

Proper data classification and encryption must be performed (ISACA, 2011). In the early Google Wallet case, it was clear sensitive data was not properly classified and/or encrypted. Encryption often isn’t done properly because data is not classified to be encrypted or encryption is not implemented properly. The best strategy would be to use FIPS 140-2 cryptographic for all sensitive data-at-rest, data-in-transit and data in memory or process.

Providing layers of security and containerization is vital to securing a mobile environment (“National Security Agency”, 2013). By applying layers of security there are levels of redundancy to increase security. Application containerization/isolation needs to protect data in memory or process with FIPS 140-2 certified cryptography.

5. Conclusion

    Mobile payments allow a mobile device user to pay for a product or service using one of two technological capabilities: proximity and remote payments. Proximity payments are done mostly using NFC and most remote mobile payments are when a browser or application must authenticate and authorize to access personal information stored at a remote location. The mobile payments industry is expected to grow by $400 billion in the next 4 years. The wide range of mobile device technology, payment applications, remote payment locations, and explosive growth of mobile payments provides malicious actors with a large attack surface, thus increasing the risk for exploitation. Four main areas are discussed in order to get a better understanding of the risks: (1) A security analysis of two popular mobile payment applications, Google Wallet and Apple Pay; (2) A look at the top security risks to the mobile payment ecosystem; (3) A list of the top 10 mobile application risks; and (4) Strategies to address the risks.

    Google Wallet’s security analysis focuses on NFC, the Android OS itself, storage techniques of personally identifiable information (PII) and credit cards, and risks introduced with rooted devices. Apple Pay’s security analysis focuses on their dynamic anonymous payment procedure resulting in increased security, biometric authentication, and the number of parties involved to complete a payment. The result of analysis of these two popular mobile payment methods is that there are always risks, but security is improving as shown with iterative improvements to Google Wallet and introduced in Apple Pay.

    Risks to the mobile payment industry has 3 main attack surfaces: (1) The user; (2) The network or communications provider; (3) The payment service provider. Nine risk categories associated to these participants are discussed, along with the associated threats and vulnerabilities. Potential countermeasures are provided that can help mitigate the risk categories. The Open Web Application Security Project (OWASP) top 10 mobile security risks are also provided. The OWASP list is not specific to mobile payments, but is important to discuss so that those implementing security are aware of all major security risks.

    Most mobile payments are made using a mobile application, such as Google Wallet or Apple Pay. Hundreds of other mobile payment applications exist in Google Play and the Apple App Store. It is therefore important to discuss the top mobile application security risks to understand all major attack vectors.

    There are a number of strategies that can be used to help mitigate risks associated with mobile payments. The five main strategies discussed are: (1) Proper testing policies and procedures can reduce exposure to risks; (2) The use of multi-factor authentication; (3) Using dynamic card verification values (CVVs) when NFC technology is used for proximity payments; (4) The use of proper data classification and encryption be performed; and (5) Layers of security. A high level of security can be accomplished by implementing these five strategies, along with specific countermeasures to the listed top mobile, mobile payment, and mobile application risks.

6. References

"52 Factorial." 52 Factorial. CZEP. Web. 14 Nov. 2014. <http://czep.net/weblog/52cards.html>.

Ba, Jing. "Analysis of Security Risks in Mobile Payments: A Case Study Using DNAT." (2013).

Carrington, Denée. "US MOBILE PAYMENTS FORECAST 2013-2017: Mobile Payments to Reach $90B by 2017." Denée Carrington's Blog. Forrester Research, Inc., 16 Jan. 2013. Web. 13 Oct. 2014. <http://blogs.forrester.com/denee_carrington/13-01-16-us_mobile_payments_forecast_2013_2017_mobile_payments_to_reach_90b_by_2017>.

"CCC | Chaos Computer Club Breaks Apple TouchID." Chaos Computer Club. Chaos Computer Club, 21 Sept. 2011. Web. 11 Nov. 2014. <http://www.ccc.de/en/updates/2013/ccc-breaks-apple-touchid>.

Cherrington, Aaron, and Greg Day. "Apple Pay: A Security Analysis." FireEye Blog. FireEye, Inc., 19 Sept. 2014. Web. 6 Oct. 2014. <http://www.fireeye.com/blog/corporate/2014/09/apple-pay-a-security-analysis-2.html

Golany, Yanai. "Google Wallet Overview – Threats and Security Measures." MIT Geospatial Data Center. Geospatial Data Center Media, 9 Oct. 2012. Web. 6 Oct. 2014.

Haselsteiner, Ernst, and Klemens Breitfuß. "Security in near field communication (NFC)." Workshop on RFID security. 2006.

ISACA. "Mobile Payments: Risk, Security and Assurance Issues." ISACA. ISACA, 1 Nov. 2011. Web. 6 Oct. 2014. <http://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/MobilePaymentsWP.pdf>.

Morrow, Stephen. "How Will Security Testing Help to Reduce Risks and Build Customer Confidence in Mobile Payments." SQS. SQS Software Quality Systems AG, 1 Mar. 2014. Web. 6 Oct. 2014. <http://www.sqs.com/uk/_download/whitepaper-mobile-payment-security.pdf>.

National Security Agency. Mobility capability package. 29 Jul. 2013. Web. 21 Oct. 2013. http://www.nsa.gov/ia/_files/Mobility_Capability_Pkg_Vers_2_2.pdf

Nichols, Brian. "How You Make Payments Will Drastically Change in Coming Years." The Motley Fool. The Motley Fool, 4 Aug. 2014. Web. 18 Oct. 2014. <http://www.fool.com/investing/general/2014/08/04/how-you-make-payments-will-drastically-change-in-c.aspx>.

"OWASP Mobile Security Project - Top 10 Security Risks." OWASP. The OWASP Foundation, 29 Sept. 2014. Web. 6 Oct. 2014. <https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_10_Mobile_Risks>.

Pollock, Clint. "The Mobile App Top 10 Risks." OWASP. VeraCode. Web. 6 Oct. 2014. <https://www.owasp.org/images/9/94/MobileTopTen.pdf>.

Porteous, David. "The enabling environment for mobile banking in Africa." (2006).

Ray, Raja. "The Many Flavors of Mobile Payments – 3 Types Explained." The VeriFone Blog. VeriFone, 14 July 2014. Web. 13 Oct. 2014. <http://blog.verifone.com/all-industry-verticals/many-flavors-mobile-payments-3-types-explained/>.

Sun, Weichao. "Vulnerability in In-App Payment SDKs May Lead to Phishing." TrendLabs Security Intelligence Blog. Trend Micro, Inc., 21 Aug. 2014. Web. 5 Nov. 2014. <http://blog.trendmicro.com/trendlabs-security-intelligence/vulnerability-in-in-app-payment-sdks-may-lead-to-phishing/>.

Webster, Karen. "How to Make Mobile Commerce a Profitable and Worthwhile Opportunity." PYMNTS EBook. 1st In Media, LLC, 1 Jan. 2012. Web. 11 Nov. 2014.

Westervelt, Robert. "PayPal, Wells Fargo Among Most-Spoofed Sites During Holidays." CRN. The Channel Company, 3 Jan. 2014. Web. 6 Oct. 2014. <http://www.crn.com/news/security/240145468/paypal-wells-fargo-among-most-spoofed-sites-during-holidays.htm>.

von Behren, Rob, and Jonathan Wall. "Coming Soon: Make Your Phone Your Wallet." Official Google Blog. Google, 26 May 2011. Web. 19 Oct. 2014. <http://googleblog.blogspot.com/2011/05/coming-soon-make-your-phone-your-wallet.html>.

Xue, Hui, Tao Wei, and Yulong Zhang. "Masque Attack: All Your IOS Apps Belong to Us." FireEye. FireEye, Inc., 10 Nov. 2014. Web. 28 Nov. 2014. <https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html>.