Of all the complaints anyone is going to lodge about an Apple product these days, insufficient security is likely not too high on the list. In fact, some — like the Department of Justice — would really, really like if Apple could bring itself to be just a little bit less secure. In the case of one iPhone anyway.
That dedication to security was baked into Apple Pay pretty much from the word “go” — with two different independent variables. To use Apple Pay at all, users had to unlock the system via a biometric scan with the Touch ID fingerprint system. Once a user’s identity is verified, Apple Pay releases payment information via data token — an encrypted bit of data that stands in for a card number in a transaction.
Tokens, said simply, are useful by the very nature of being useless — or, at least, useless to anyone lacking an encryption key that turns that tokenized data package back into something usable.
And, of course, all that payments-specific security sits on a phone that is extremely difficult to hack in and of itself.
Like all new products, Apple Pay has been on the receiving end of complaints since its release a little over a year ago, but almost none have centered on security. Despite its challenges with merchant and consumer adoption, there’s almost a universal agreement that when it comes to keeping users’ most sensitive data safe from harm, Apple has proven to be more than up to the task.
Hooray, right?
Well, it depends. Apple Pay remains open and rather susceptible to an array of easy and old-school forms of “hacking.” And even that term may be a bit misleading, since simply stealing a card number and running wild is a form of fraud that predates the concept of the “hack.”
The hole is not Apple’s fault, per se, but it certainly turns out to be its problem, as the firm’s payments platform is becoming a surprisingly easy way to effectively use someone else’s card.
Good-old account takeover strikes again.
So, what’s up?
Once In, Cards Are Secure. Adding A Card On The Other Hand…
The security issue stems from when one adds cards to the Apple Pay wallet. Credit card numbers are relatively easy to come across if one knows which end of the Dark Web to look in; Forbes reports that the going rate for a card is about $2. With the advent of EMV chips, however, the easiest use for those cards when it comes to making an in-store purchase — cloning — is getting increasingly closed off.
But Apple Pay is apparently offering a new avenue for the thieving types who don’t want to be limited to using their ill-gotten card numbers online. By entering a stolen card into an Apple Pay wallet, a thief can go in-store and make a purchase — provided they are at one of the few locations that can take Apple Pay.
There is, of course, a big “if” here, and that “if” is the issuing bank and how careful it is about letting cards get provisioned into digital wallets. A new — and very informal — study by anti-fraud firm Pindrop would indicate that levels of caution vary quite widely from issuer to issuer.
Some check up pretty carefully, some are rather lax and others essentially offer no protection at all (if one can competently type all the digits and CVV code into the wallet, they are ready to rock ’n’ roll).
So Who’s Checking (And Who’s Not)
In fairness to the issuing banks being called out, it is worth noting that Pindrop’s research here was far from scientific.
Pindrop researcher David Dewey basically took up a collection, asking for his coworkers’ card numbers. He then added those numbers to his Apple Pay account and waited to see what happened. All in, four different banks were tested, though Dewey has not said which four.
What did he learn?
One provider really was happy with just the numbers — no other security methods were employed. For a different provider, he noted that a check was performed if the name on the card did not match the name on the Apple Pay account. Switching names was adequate to stop any security inquiry.
One provider did force Dewey to call. However, using the magic of Google, he was able to provide enough information about his colleagues to pass the screening and gain use of their cards in his account.
Dewey’s total review of the situation?
“If you want a quick and dirty way, this is it,” he said. “Fraudsters and hackers are like water: They’re going to take the easiest path to get what they want. Right now, this is that easiest path … There’s no point of even trying to find a vulnerability in EMV because this works so well.”
Eww.
So Who’s To Blame: The Banks Or Apple?
When Forbes reached out to issuers about Pinpoint’s findings, all offered a similar, if vague, answer: They do something to verify users before allowing the provision of cards in mobile wallets, but they won’t say exactly what it is — for security reasons.
And Dewey noted that though banks bear the brunt of the blame here, Apple is not totally blameless, since Dewey was not able to do the same trick with competitors’ mobile wallets, using the same cards.
“We tried the exact same cards between the others, and security issues that arose in Apple Pay were not present in Samsung [or Google],” he noted.
The most glaring omission, according to Dewey, is the lack of “rate limiting” in Apple Pay, which prevents hackers from guessing a piece of information they may lack (usually, the CVV number).
There are only 1,000 three-digit number combinations, and a computer can run through all of them fairly quickly until it enters the correct one, allowing hackers to brute force their way into Apple Pay. Samsung and Google both stop that by limiting the number of entries a user can make incorrectly before shutting them out.
“[Google and Samsung] have been much more diligent about preventing automated brute force attacks,” Dewey noted, meaning they aren’t relying on banks to catch fraudsters so much as they are proactively working against them in-app.
“Apple Pay is standing on the shoulders of so many different security systems … there’s not one fundamental flaw; it’s just bad security design,” noted Vijay Balasubramaniyan, CEO and cofounder of Pindrop.
Apple did not respond to PYMNTS’ request for comment on this story.