There are more ways to pay for goods and services than ever before. New payment technologies bring growth opportunities for businesses, and they can revolutionize customer experiences at point-of-sale.
However, these new apps and technologies also present payment providers with new types of threats. In order to provide high-security experiences for users, security must be built into these new apps and technologies from the ground up. But there’s reason to believe that ship may have sailed.
The very architecture and developer languages chosen for the latest crop of mobile financial apps and payment solutions like Tap-To-Pay and Pin-On-Glass haven’t necessarily been chosen with security in mind. Therefore, they may have fundamental, systemic vulnerabilities open to compromise.
As smart payment technologies rose to prominence, simple mag stripe readers with virtually no security were ubiquitous among businesses for whom larger PEDs are cost-prohibitive. Luckily, more secure options have come to market since the EMV migration has begun in the United States. These options, such as downloadable mPOS and PIN-on COTS, bring more security than a simple mag stripe, but not nearly enough to meet a financial institution’s standard.
In the past, a payment terminal was a standards-compliant, extensively-researched and secured hardware device that was purpose-built for processing secure transactions. Now, any device with the necessary features can become a payment terminal. Additionally, that device handles all of the transaction processing. Naturally, these changes prompt security challenges.
Tap-To-Pay systems present a particularly novel protection trial; not only are these devices often owned and maintained by non-tech-savvy end users, but they serve numerous purposes each day. One minute a user is playing Candy Crush, and the next they’re executing and processing transactions to and from the world’s largest financial institutions—all on the same pane of glass. Historically, payment systems have segregated the transaction itself from the card’s credentials, but this is no longer the case, presenting a new structural vulnerability for fraud.
Since a smartphone will be managing on-boarding, authentication of the account, cryptographic processing and securely communicating with all involved parties, the security of the device itself is of primary importance. Yet, it is well-known that jailbroken or rooted devices exist around the world and are easily masked from detection on a network. Payment apps must cope with this reality and keep data safe even on compromised devices, so the architecture used to build these applications becomes crucially important. Some apps are only offered on certain platforms for this reason, and others are certified to meet certain standards of protection. App developers must assess platforms for their architecture and security capabilities to best protect sensitive financial data. Even root detection, the ability for an application to identify if the device is more susceptible to intrusion, depends upon an outdated blacklist/whitelist approach, and therefore, knowledge of prior attacks.
So what can a developer do to secure their user’s data in transit, in storage and in use? First off, crypto data must be able to run in a protected environment. The app’s code also needs to be protected from analysis, both static and dynamic. And furthermore, secure and authenticated access must be ensured.
Mobile devices are the most effective hacking tools available today. Used by billions and sharing standardized characteristics, smartphones aren’t able to be protected with traditional IT security techniques. Since operating systems can’t be trusted, the most notable control a developer has is over the app itself. That’s where security really begins.
To read the original article: