The demand for paying with mobile devices may have gotten off to a slow start, especially in the United States, but the next few years will see the mobile payment landscape explode – IDC estimates that by 2020 the global mobile payment market will be worth nearly $4 trillion.
From paying bills and transferring money to friends and family, paying for coffee before we enter Starbucks, to ordering clothes, food, cabs, and other services – all done through our mobile devices – the landscape for mobile payments has dramatically increased – and security has been left in the dust.
The number of capabilities offered by the many mobile payment channels available – POS applications and NFC-based payment apps to systems built into the mobile OS – has made mobile payment apps a ‘godsend’ for consumers who ache for more convenient ways to pay. And with reduced costs, increased operational efficiency and, of course, higher customer satisfaction, mobile payment applications have been great for businesses, too. But it’s cast a dark shadow on security implications created by all the accessibility offered by mobile payment applications.
Take, for example, ISACA’s recent Mobile Payment Security Study, which found that around 89% of the cyber security professionals surveyed know that cash is the most secure way to pay – yet only nine percent of them actually prefer to pay in cash. Another 87% of those same security experts expect to see an increase in mobile payment data breaches in 2016. If cybersecurity professionals themselves are unconvinced by the prospect of higher risk when paying with their phones, there is only one practical thing to do: begin increasing security practices when developing mobile payment applications. Security doesn’t have to be a trade-off for convenience – and to succeed in the future of mobile payment apps, we all need to work towards finding ways to make that a reality.
Why Mobile Payment Security Is Different:
Mobile devices have so many different touch points – device manufacturers, mobile OS developers, application designers, among others – that attention to the security provided by your mobile payment app is absolutely vital to the vitality of your organization and the loyalty of your customers. In addition, because of the speed at which the mobile app market runs, development for apps is often done with a rush to release – and more often than not, security suffers.
Because there are so many different functionalities and additional communication methods offered by mobile devices, each needs to have special attention paid to ensure full security. In addition, the majority of security controls used on mobile devices, including password protections and biometric inputs, secure the phone only in instances of physical theft, and not through the myriad other ways attackers can get through.
These unique challenges mean that mobile payment app developers need to pay special attention to areas that aren’t as crucial when developing other mobile applications or software.
Here are seven tips to get you on your way to making secure mobile payment applications:
There are pros and cons to writing your code for the specific mobile operating system it’s intended for. Some of the positives include a more native feeling for users and runs more smoothly, but the downside is that each OS is unique and requires a different language along with different testing environments and tools used for development.
On top of the differences between operation systems, different versions of the same OS each have their own security implications that need to be taken into consideration.
Hybrid platforms that help bridge the gap between OS’s for applications, such as PhoneGap offer a third option for developers. And while in the end it’s up to your organization to make that decision, one thing to be fully aware of are the security implications for whatever OS you do choose.
Leakage and data theft are major risks involved in mobile apps in general, yet with so much financial information involved with mobile payments and mobile banking, the risks are that much higher. Keep data on the device only as long as the user session is in place, and always in a secure storage environment.
Don’t fall prey to the mistake the Starbucks iOS app last year. Their application, used to store loyalty cards which paid for products, was found to be storing “passwords, emails, usernames and GPS location files in plain text,” the LA Times reported.
Luckily, both instances were detected by ethical hackers and reported responsibly to the companies in question. But it was just that – luck. Organizations developing mobile apps cannot afford to rely on the “good guys” to always find their security flaws.
Insufficient Transport Layer Protection is one of OWASP’s Mobile Top 10 vulnerabilities, and it’s vital to ensure the protection of user’s data as it’s moved across networks. SSL/TLS should always be used to transmit sensitive info, always require the SSL chain to be verified and avoid mixed SSL sessions. A good piece of advice is to assume the user is going to be using the app over insecure Wi-Fi – and develop your app and security processes around that.
As Al Pascual, director of security risk and fraud for Javelin Strategy and Research told Dark Reading earlier this year, “the one constant we have seen for every mobile financial service thus far has been the issue of [bank account] takeovers, whether that be mobile banking, mobile RDC, or mobile payments. More needs to be done to ensure that the device to which data is provisioned belongs to the legitimate account holder.”
In our State of Mobile Application Security report, we reported that nearly a quarter of vulnerabilities uncovered by security testing were owed to authentication, surpassed only by the leakage of personal or sensitive data. More alarming was that 60% of authentication and authorization issues were found to be of critical severity.
Earlier this year, a security vulnerability surrounding the Apple Pay mobile payment technology that saw “rampant” fraud made that severity all too real. The fault for the fraud lay with the banks, though. Criminals were stealing credit cards, uploading the info to Apple Pay, and, with lax approval methods on the banks side – including call centers, the thieves were able to use their own phones to make purchases on someone else’s dime.
To combat authentication issues in your mobile payment applications, strong mechanisms need to be able to ensure the identity of the user. Gartner analyst Avivah Litan recommends lower reliance on static data such as social security numbers or PIN codes, and put more focus on dynamic data such as Google Authenticator or instant SMSs provide. Litan also recommends slowing down the authorization process for especially high-risk applications.
Third-party and open source libraries are incredibly handy for developers in the face of just quick-changing and different types of environments, and they’re used widely in mobile apps. But don’t be fooled by the “more eyes make all bugs shallow” myth. These libraries require security testing just as the rest of your code does. Developers need to be aware of the risks these libraries can pose (POODLE, Shellshock or Heartbleed, anyone?) and security managers should educate developers in the security risks they should be looking out for – both in third party libraries and the code they write themselves.
With all due respect to fast development and rushed timetables, security testing is not an extra function that can be thrown in at the end of development ‘for kicks’. Code scanning and remediation of detected vulnerabilities throughout the SDLC is an essential part of the fast-paced app development environment because it saves vital time and resources in the end.
It’s been proven time and time again how much repairing security bugs at the beginning stages of development saves in the end, and it’s no different with mobile payment applications. Once you’ve chosen the correct tools for the job, the next step is developing a plan for how security testing will be implemented throughout development.
Your work with mobile payment application security is never done. Once you’ve released the payment application to the wild, an important part of the follow-up is to regularly scan the code for new security vulnerabilities, update security libraries when new versions come out, and listen for user feedback regarding security or privacy concerns.
Don’t assume that just because your app has hit the app store you can forget about it. Security never ends, because the attackers never stop.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.