Snippet: On the weekend, I finally had a chance to load my three credit cards into Apple Pay. The process was slick and painless, as you’d expect from Apple: a simple snap of the credit card auto-populated the data on my phone. Only the card security code (three or four digits long) is entered by hand.

On the weekend, I finally had a chance to load my three credit cards into Apple Pay. The process was slick and painless, as you’d expect from Apple: a simple snap of the credit card auto-populated the data on my phone. Only the card security code (three or four digits long) is entered by hand.

Below, I’ll explore the security mechanisms I encountered during the Apple Pay enrollment process, as well those in place for making actual payments.

Enrollment with one-time passwords

One of the inherent risks in any authentication solution is the initial onboarding or identity proofing process. In many deployments, a simple username and password offer greater security than a hardware token does because the identity proofing intended to pair the token with a specific user is not sufficiently rigorous.

Since Apple Pay is in essence a legal “card cloning” service (by simply taking a picture of a card on my phone, I can now pay with my phone), measures must be implemented to ensure that only the rightful owner of a credit or debit card can add it to Apple Pay. Apple solves this problem with an archaic multi-factor authentication technology: the one-time password (OTP).

Your card issuer has your mobile number or email address on file. This enables it to send an OTP to your phone via SMS or email when you scan your card. Inversely, if someone takes your card and attempts to fraudulently link it to their Apple Pay account, they would be stopped from completing the process because they don’t have access to your SMS inbox or email account.

Apple is resting the security of the Apple Pay enrollment process on the security of SMS and email. Trust in these channels is not uncommon in the banking world, but both have a solid history of compromise once you start looking beyond the US to Europe, Asia-Pacific and Africa. In countries like Australia, the mobile carriers have gone as far as declaring SMS “unsafe” for banking transactions. It’s an unencrypted technology with very basic levels of authentication.

Since Apple Pay has such a small share of in-store transactions, I don’t foresee it becoming the focus for fraudsters over the next month or two, but when US issuers and merchants start their migration to chip-based technologies, the fraudsters could pounce. Apple Pay might be the perfect target: a ready-made, extremely intuitive card cloning solution.

Apple’s partial tokenization

Once your card has been successfully “cloned” in Apple Pay, you’re all set to shop! Here’s where tokenization comes in. The idea behind tokenization is that every time you want to make a payment at a point of sale, instead of just handing over a standard 15- or 16- digit card number (the primary account number or PAN), which remains the same for the lifetime of the card, you provide a randomly-generated number that’s only valid for one transaction.

It’s hard to do something like this with a plastic card but fairly simple if you have a small computer in your hand that can receive the unique card number (token) every time a request for a transaction is received from a point of sale system. With systems like these, the Target and Home Depot breaches would not have made even local news; the data the fraudsters absconded with would have been expired tokens – useless to them.

Apple Pay’s implementation of tokenization is only partial. A new token is not generated every time you transact but, rather, every time you add a new card to the system. So the data transmitted to the merchant through Apple Pay could still be misused, at least until you delete the card from your phone and re-enroll it, at which point a new token is generated.

Why has Apple gone this way? I would speculate that, because of the limited number of possible permutations in a PAN. Only part of the PAN identifies the individual card account, so there is simply not enough entropy in the system to allow for a brand new number every time a transaction is performed. This problem might be solved in future by introducing longer PANs, but the inertia in the payments world won’t allow for that at present.

Another reason may be that chargebacks and recurring billing would be a nightmare in a fully tokenized world – unless the complete ecosystem is aware of it. The Apple Pay tokenization scheme is certainly a step in the right direction, but there’s still a lot of work we all have to do to secure digital payments.

Subscribe to our blog.


Christiaan Brand

FORMER CTO

Entersekt Logo

Entersekt is an innovator of customer-centric fintech solutions. Financial services providers and other enterprises rely on our patented mobile identity system to provide both security and the best in convenient new digital experiences to their customers, irrespective of the service channel. With us, they can concentrate on their innovation roadmap, while delivering intuitive, low-friction digital experiences to their customers.