With the official launch of Apple Pay today, I wanted to take a moment and talk about the potential pro’s and con’s of using an eWallet in general (Google Wallet or Square for example) and Apple Pay specifically.
Let’s start with the fundamentals. Google Wallet, Square, Apple Pay and most other eWallet options rely on NFC to transmit and receive data. NFC stands for near field communications and is a proximity-based network technology built into many popular smartphones including the Samsung Galaxy s5 and the iPhone 6. NFC operates in a range of approximately 3 – 10 cm and over a frequency of 13.56MHz. The basic procedure for a physical purchase transaction using NFC via a smartphone goes something like this:
– Customer selects a payment option on his/her phone – Customer holds the phone an inch or two from the retailer’s payment terminal – A few beeps occur and like magic, the transaction goes through.
To the consumer, this type of payment option seems like a great deal. No cards were swiped. The phone remained in their possession. They didn’t even have to reach for their wallet. Unfortunately, from a fraud perspective, a few things are left to be desired.
Let’s start by discussing the pitfalls of traditional NFC eWallets like Google Wallet. Even though a physical card is not swiped during the transaction, Google Wallet and most others in this traditional category still transmit cardholder data in that brief NFC network session. By cardholder data, I am referring to those all-important 16 digits on your credit or debit card as well as some other personally identifiable information necessary to complete the transaction. This means that your card info is still vulnerable to the same types of malware within the retailer’s network that caused breaches like those reported at Target, Kmart and others.
Another issue that arises in this scenario is that the same card information we are afraid to hand over to the retailer is now living on our smartphones. Without proper security (locked screens via passwords or biometrics, phone encryption, remote kill switches), a lost or stolen phone becomes as dangerous and critical as a lost or stolen wallet. At the end of the day, I believe that traditional NFC-based eWallets are not any worse than traditional card-based transactions, but they are also not significantly better.
Now let’s take a moment and explore some of the differences found in Apple’s eWallet solution, Apple Pay. Apple Pay is a tokenized solution meaning that a randomly generated token is passed via the NFC transmission in the place of actual cardholder data. This is possible through Apple’s partnerships with First Data and other banking institutions and merchants. This tokenization process eliminates some of the risk incurred by traversing a retailer’s network that might be infected with malware. The cardholder data is not present in the transmission for the malware to capture.
Also, no cardholder data or transaction data is captured or stored by Apple. Nothing is retained on an Apple server. All card information is stored locally in the iPhone 6 on a separate, heavily encrypted memory partition called Secure Element. Apple doesn’t even know what you bought. Apple Watch will have its own Secure Element storage for implementations of Apple Pay via pairing with the iPhone 4s/5/5s.
Even though Secure Element is present and in use, important information is still located on the iPhone that could still be lost or stolen. Apple Pay can support two-factor authentication for all financial transactions by requiring the use of Touch ID to trigger the payment process. Touch ID is the biometric reader integrated in the home button of all iPhone 5s/6/6Plus devices. This means your finger would need to be present to give value to the lost or stolen device if used for a purchase. Taking that one step further, the use of Apple Pay on lost or stolen iPhones can be remotely disabled using the “Find My iPhone” application.
Let me be clear by saying that all of these differences found in Apple’s implementation do not make it a perfect solution. Though no cardholder data is stored, Apple Pay does require a connection/association to an iTunes/AppleID account, and these accounts have been proven vulnerable over the past several months. Also, Touch ID, as a second factor of authentication, has been proven vulnerable to hacking since its release. Finally, Because of its large user base, Apple in general and Apple Pay specifically will have a huge target on its back at launch. Criminals and white hat and black hat hackers will attempt to find and exploit its weaknesses.
No technical solution deployed for payments will ever be perfect. There are too many factors in play and as humans, we will make mistakes. That said, I do believe there is significant value in a tokenized financial transaction solution, specifically when a second factor of authentication can be brought to bear. I will personally be testing Apple Pay at my earliest convenience and I will report back on my success or failure.