Like anything new in the world, Apple Pay’s purchase service began attracting some fraud last year. It increased and generated bank complaints last month. But, while the effort is not really Apple’s fault, it would be well worth it for Apple to take an active role in eliminating the problem to promote its success in the business.
What has been happening is simple enough. The acquirers of stolen cards enter the information into the Apple Pay app on an iPhone 6 and, if the theft is not spotted by the card processor, it works.
With huge volumes of card theft from retailers such as Home Depot and Target, the price of data has fallen to 75 cents or less a card. (If you want great detail on the plot and how it succeeds, read an account on the excellent Krebs on Security by Brian Krebs.)
The real lesson of large scale credit card thefts has been to demonstrate the security of cards is impossible, whether they are old fashioned magnetic stripe units or new (in U.S. terms anyways) chip equipped ones. The goal of everyone–phone makers, card processors, banks, merchants–is to eliminate cards and replace them with secure systems. But that will take years to accomplish. So we need more security for existing cards for some time to come.
The recent attack focused on Apple Pay because it is by far the most used software and hardware today, but rival plans such as Google Wallet, Samsung Pay, and the retailers’ planned CurrentC were vulnerable to the same raid. But the price Apple should play for its success is to take on the role of stopping the new phone-based systems used for fraud.
The security provided by Apple Pay was described by Apple itself online:
Every time you hand over your credit or debit card to pay, your card number and identity are visible. With Apple Pay, instead of using your actual credit and debit card numbers when you add your card to Passbook, a unique Device Account Number is assigned, encrypted, and securely stored in the Secure Element, a dedicated chip in iPhone. These numbers are never stored on Apple servers. And when you make a purchase, the Device Account Number, along with a transaction-specific dynamic security code, is used to process your payment. So your actual credit or debit card numbers are never shared by Apple with merchants or transmitted with payment.
The problem in this relationship is when the card information is entered into the Apple Pay app and sent on, for the only time, to the bank for approval. The banks have often failed to check that information, so stolen cards get approved and can be used for purchases, at least for a little while. With Apple Pay working, a card stealer or buyer is neither limited to online purchases nor creating a counterfeit card.
For better or worse, banks tend to view credit card fraud as a tolerable cost of business or, if they are lucky, a cost either the cardholder will miss and pay or a merchant will be nailed back for the cost. Avivah Litan notes the problem in the Gartner blog:
This problem is only going to get worse as Samsung/LoopPay and the MCX/CurrentC (supported by Walmart, BestBuy and many other major retailers) release their mobile payment systems, without the customer data advantages Apple has in their relatively closed environment.
The vendors in the mobile user authentication space have consistently answered that they are leaving account provisioning policies to the banks or other consumer service providers provisioning the apps. Well maybe it’s time for them to reconsider and start helping their client banks and service providers by supporting identity proofing solutions built into their apps. Whoever does this well is surely going to win lots of customer support… and revenue.
While the banks may think they can handle the losses, it is important for Apple, which has already been blamed for the problem in a number of not well-informed commentaries, to take action to avoid damage to its own reputation. A key is making sure any new credit cards are properly checked before their use on Apple Pay is authorized, either by refusing to pass it through Apple in the first place or helping the credit card processors block the losers. Actions from requiring a photo of the card (taken on the phone, of course) to be submitted when the credit card is registered to checking all card numbers submitted against the lists of hacked cards before approving Apple Pay use would help.
The hoped-for disappearance of credit cards is a long ways away. But the less we will need to use the cards, the better off we will be. That’s why Apple Pay and, potentially, the offerings of its competitors are a big improvement. Let’s not allow about some startup issues cause a problem it doesn’t deserve.
“The recent attack focused on Apple Pay because it is by far the most used software and hardware today, but rival plans such as Google Wallet, Samsung Pay, and the retailers’ planned CurrentC were vulnerable to the same raid.” That caveat had me laughing, because the same is true for malware on Windows and Android, and yet, somehow, it never gets mentioned.
BTW, Google’s security report is out ( http://www.theverge.com/2015/4/2/8327887/google-android-malware-report-2014-webview ), 0.15% (that zero dot fifteen per hundred) of PlayStore-only phones have some kind of malware. That should paid put to the “security” FUD, maybe even start a wave of retractions. I’m not willing to bet, though.
And what percentage of Android phones are PlayStore-only?
Thankfully zero! 😉
100% of those who want to be safe. The stuff not on the PlayStore is mostly pirated apps, with a sprinkle of system tools.
If not, that’s their choice, and it’s probable fairly marginal (out of 20-ish GMS-Android devices around me, all are PlayStore-only).
I was going to say this, but I’m more glad you did. Apple Pay, that “fraud infested” pay system! 🙂
(That was sarcasm. It’s always been about the good guys versus the bad guys).
Anyone know the answer?
How much notice and education does Google provide in the vein of:
“Don’t Want to be Hacked? PlayStore ONLY.”
You are correct. If that is your only concern, then that is the correct course of action. I would say you’re just as safe using Amazon’s store too, so it’s not “only”. Reputable alternate repositories can be just as safe. In that regard it’s like buying anything else.
But there are other considerations. A teacher may write an App for their students, in a language of their choosing. The teacher can just let the students download the App, or it can even be emailed to them and they can run it on their Android devices.
Actually, if you install the Amazon apps from the PlayStore, you’re still good. You get Amazon’s content, not their appstore, but their appstore is purely apps also available on the PlayStore (often older versions, too).
As for your teacher example, registering to publish apps on Google Play is a one-off $25 (and does NOT require buying a ChromeBook Pixel or some other Google overpriced device ^^). Well worth it for not having all kids compromise their phones, and can be shared with colleagues.
True. Said teacher may want to also sell the program. Not being bound to one store, or a store at all, gives them more latitude on how they choose to do it.
There are 2 ways to un-PlayStore a phone:
1- Enable sideloading. That’s a checkbox in Settings > Developper Options, and checking it ON generates an extra pop up (in case “DEVELOPER options” isn’t clear enough, stating this is for developer only, may damage phone, cause apps to malfunction, and is unsafe. This can be disabled for managed/entreprise phones. This does NOT disable Android’s permissions management, just allows for installation of unverified APKs from outside the appstore.
2- change your phone’s ROM (say install cyanogenmod), which typically involves installing a new bootloader via Java + Google’s dev tools + a specific program on your PC to change your phone’s bootloader, then from that bootloader install the new ROM. Users usually have the choice to install the gapps the same way and stay in the PlayStore, in which case security issues are limited to the original bootloader+ROM for malware and security holes. This can be checked for in managed/entrerprise phones, and offending phones reset+disabled (changing ROMs fully resets the phone to start with).
An related possibility is rooting a phone, which gives the user admin rights outside of the walled garden, and allows him/her to take apps (usually one by one, w/ a manual operation+ safety confirmation dialog) out of that walled garden too. That’s typically done the same way as installing a rom: install Java + Google’s dev tools + a specific program on your PC, then another app on your phone to manage other apps’ permissions, and can be done either on stock phones or alternate-ROM phones. Managed/entrerprise phones can check for that too. This does disable the permissions management system for “upgraded” apps
Security-wise, the really deadly combo is rooting+sideloading+upgrading random apps’ permissions. As you can infer from the explanations, this requires more tech knowledge than most people have, and does require confirming through several unequivocal warnings. Can’t be done by accident, and for most people… can’t be done at all ^^
It’s not Apple’s fault that the banks don’t check, but Apple is in bed with the banks, and they benefit from the system, so they get deserved heat as well. They best do something about it, if they can.
Here’s how to fix it .. Use CASH or your debit card , i mean really is it that hard to pull out your debit card or get cash in ur pocket to pay for things … these pay options are just another go between to get their hands on your cash one dollar at a time (that add up) by having to have to pay for a service that is totally unnecessary … not to mention another door for hackers ….