Apple Pay has enjoyed a fair amount of praise since its launch late last year. But thanks to a recent string of possible security flaps, the mobile payments darling is facing some harsh scrutiny.
A report from security journalist Brian Krebs suggests that a lapse in verification between banks and Apple Pay could allow identity thieves to use CVVs (card verification values) hacked from online stores to link stolen credit card data to an Apple Pay mobile wallet.
For now, it's unclear how much this scenario would play out in practice. What's clear is that Apple Pay will be a bigger target for cybercrime simply due to its popularity and rapid adoption. We've reached out to Apple for comment.
According to Krebs, CVVs, which were previously only useful for fraudulent purchases made online, could now be used by cyber thieves within brick-and-mortar stores. As Krebs explains, when an identity thief buys a CVV, they get the credit card number, the expiration date, the card verification code and all of the cardholders personal information, such as name and address.
Then, these cyber criminals can use that stolen data to set up new iTunes accounts, and then use those iTunes accounts to provision new Apple Pay accounts.
Why is that process so simple? For one, it was designed that way, both by Apple Pay and the banks, in order to make the sign up process seamless and the adoption rates higher. Card issuers went so far as to "green path" Apple Pay accounts, meaning that no additional authentication was needed for an Apple Pay user to get their wallet up and running, other than measures built into the iPhone.
Here's the take from Krebs on Security:
Enter Apple Pay, which potentially erases that limitation of CVVs because it allows users to sign up online for an in-store payment method using little more than a hacked iTunes account and CVVs. That's because most banks that are enabling Apple Pay for their customers do little, if anything, to require that customers prove they have the physical card in their possession.
The irony here is that while Apple Pay has been touted as a more secure alternative to paying with a credit card, the way Apple and the banks have implemented it actually makes card fraud cheaper and easier for fraudsters.
The irony goes further because a huge amount of fraud tied to this particular Apple Pay scenario is linked to purchases of Apple products, within Apple's brick-and-mortar stores.
While the fault in this whole scenario is certainly debatable, the general consensus seems to rest the blame more on the side of the credit card issuers and banks, and the policies they use to validate the Apple Pay/credit card connection.
Currently, a few banks require authorization via email or phone, where they take extra measures to confirm a cardholder's identity -- but those measures are clearly not enough to counter sophisticated hack attempts by cyber thieves.
Still, that doesn't mean Apple is absolved of all responsibility, nor should they be. Apple Pay is an Apple product, branded with the Apple logo and used by Apple fans and aficionados. That means Apple has a serious stake in the matter and should be concerned if their flagship payment product is viewed as an enabler of fraud.
It should be noted, however, that Apple Pay users are not the fraud victims in this scenario. It's the people who had their sensitive information stolen from either personal lapses in security or large scale data breaches like those that hit Target and Home Depot.
What's more, the Krebs report puts further blame on the issuer side due to their lack of pushback on Apple itself. Had banks demanded more transparency and traceability from Apple, more secure validation practices could have been set in place right out of the gate.
But even if stricter validation methods had been set up, or if they're instituted sometime in the future, the result is a battle between convenience and security. If something becomes too secure, it hinders the convenience factor, and vice versa. It will take an effort from both Apple and the banks to strike the right balance.