SAN FRANCISCO–Apple has touted its Apple Pay system as a convenient, simple, and secure alternative to using physical debit or credit cards. But researchers have identified some weaknesses in the enrollment and authentication flow of the system that could have allowed attackers to add stolen cards to their own Apple Pay accounts and use them with impunity.
The Apple Pay system has been available in the United States for several months and relies on a number of discrete pieces to work. When a new user enrolls in the system, she will be prompted to automatically enroll the card that is already associated with her iTunes account. To add a new card, the user has to either enter the card number, name, and CVV, or take a photo of the card with her phone.
During this process, Apple sends the information to the card issuer, who can approve or deny the enrollment, or ask for more cardholder information. Depending on which issuer is involved, this could involve entering a code from a text, following a link in an email, or answering knowledge-based authentication questions. If that all works correctly, the card is enrolled and the user is off and running. But one of the weaknesses in the flow is that the issuers decide on their own how much of Apple’s data to take in.
“Apple is going to provide some information to the issuer when you enroll that card and it’s up to the issuer to decide how much of that information they want to pay attention to,” said David Dewey, director of research at Pindrop Labs. “How hard is it to sidestep that enrollment flow?”
Not as hard as it should be.
To test the security of the Apple Pay enrollment flow, Dewey created a test Apple ID, which is the master identity for Apple customers, and then collected credit cards from four different volunteers. He then tried to enroll each of the cards, which all have different names on them, in Apple Pay for the test ID. He ran the experiment for the first time in April and then again in September, and while each card issuer required different levels of authentication to complete the process, none of them was insurmountable, and most weren’t even challenging.
The first card issuer asked Dewey to either go into the issuer’s mobile app to verify the enrollment or answer some KBAs. With a quick Google search, he was able to find the information he needed to answer the questions and the card was enrolled.
“The only thing was that the customer service rep asked me if I knew I was adding a card that didn’t match the Apple ID. I said it was fine and then went into iTunes and changed the name on the account,” said Dewey, who is giving a talk on the research at the RSA Conference here Tuesday.
The second card issuer was a little more challenging, asking Dewey for a second-level verification. He had to answer some KBA questions, as well. The third issuer presented no obstacles at all, verifying the card right away. However, that issuer had changed its process by the second time Dewey ran the experiment. He had to call the issuer and get an authorization token, which he then had to recite over the phone before he could enroll the card.
There are a variety of ways to verify cards and users, and Dewey said that doing it inside a bank or card issuer’s app is probably the best one.
“Authentication through an app is very secure, because if they’re doing it properly they know specifically it’s your device they’re sending the authorization to,” he said. “A phone call is the weakest of these possible options.”
Most of the issues Dewey discovered in his research were fixed by the card issuers by the second time he ran the experiment. One of the issuers that asked for a CVV didn’t limit the number of time you could attempt to enter the number, so Dewey will demo a tool during his talk that will cycle through all of the possible three-digit CVV combinations.
