Data is compromised so frequently these days that it seems like nothing is safe anymore. So one would be forgiven for thinking that using apps that require the user to voluntarily submit payment card information in order to function -- think Venmo, Uber, etc. -- would be a risky play.
The reality, however, is that these kinds of apps are actually no more risky than any other transaction involving payment cards.
"Look at it this way: when you buy something online using a credit card, a website is literally doing the exact same thing," says Tyler Shields, a senior analyst for Forrester. "If designed properly, that's all a mobile app is...a component to access data stored on a server."
Though Shields admits that developers don't necessarily always follow best practices, they generally avoid having apps store any sensitive data locally on the device. Instead, when users submit their payment card information, it's submitted via a one-time encrypted transaction to third party backend servers managed by a payment processing company.
"What typically happens is the company that is accepting payments stores the username and email address along with some sort of reference number that is completely independent of your credit card information," says Mathew Rowley, a technical director at the NCC Group.
From then on, the card information is stored in an encrypted fashion on backend servers and never comes back to the client through the application again. In order to make transactions, the app simply pings the encrypted card on the server using a private key to decrypt it, making sure that information never hits the airwaves again. Typically payment processing centers provide developers with an SDK to plug into their application so they can securely communicate over web interfaces, but Rowley notes that things sometimes get problematic when companies try to take that responsibility on themselves.
"Some companies try to do a custom, create-your-own-encryption scheme," he says. "That's where the flaws usually come in -- trying to make that communication channel secure."
Locking down the app
Aside from trying to secure communication channels, there are additional security measures that app developers are beginning to employ. However, they have yet to become the norm, according to Shields.
"There are more advanced techniques being used in a few cases," he says. "Banks are using app protection and app hardening techniques, where they're hardening the client side with fraud protection or anomaly detection."
For instance, developers can put code into the app that checks to see if the device is jailbroken and if it is, it won't allow it to connect to the servers. Code can also be inserted to determine if apps on the device are known or if there are rogue apps.
"So it's looking for indicators of compromise," says Shields. "Eventually those techniques will fill the gap to the more common apps, but right now, they're mostly used in the banking sector."
Joe Schumacher, a senior security consultant at Neohapsis, adds that some developers implement code obfuscation to prevent apps from being decoded or looked at through the source code. Without that kind of protection, there's nothing stopping attackers from disassembling the app and obtaining -- and subsequently using -- any sensitive information they may find.
"So you have to be careful how code is written and what you're putting into your code," says Schumacher. "You don't want to put in usernames and passwords."
Malwarebytes Labs researcher Armando Orozco agrees that attackers would normally look at the apps themselves for vulnerabilities, because some apps in the past have kept confidential information stored as a text file in the data area of the app or on an SD card. As such, he has found that deck scramblers are especially useful as a first line of defense.
Find your next job with computerworld UK jobs