Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

9/11/2014
01:00 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Apple Pay: A Necessary Push To Transform Consumer Payments

Apple Pay is a strategic move that will rival PayPal and other contenders in the mobile wallet marketplace. The big question is whether consumers and businesses are ready to ditch the plastic.

On Tuesday, Apple announced an exciting new feature, Apple Pay, a mobile wallet payment system available on the new iPhone 6 and Apple Watch devices. My initial reaction to the announcement was "Not another mobile wallet option!" After researching implementation details, my attitude quickly changed and I became intrigued.

Apple Pay enables a safe and secure transaction between Apple devices and a retailer’s contactless payment reader or online storefront. The consumer avoids the tedious step of swiping or entering credit card numbers or passwords since it's already stored in Passbook, an application first introduced in iOS 6.

What’s important is how Apple Pay transforms traditional theft-prone credit cards into a unique Device Account Number stored securely on a special chip in the device. It then pairs that number with transaction-specific dynamic security codes. This ensures that intercepted transactions cannot be used to conduct fraud, because each security code is only good for the one transaction. This is the most obvious benefit, similar to the protections in place with EMV: to prevent the chips from being copied.

Another less obvious security benefit Apple Pay has over EMV is that sensitive card data is never handled by the merchant. As demonstrated in my recent Black Hat USA presentation, EMV passes plain-text card data to point-of-sale systems, which can later be stolen by RAM scrapers and used to commit fraud. With Apple Pay, the physical phone becomes the sole point for potential exploitation. Hopefully, Apple has implemented significant and sophisticated measures into protecting card data stored in the iPhones' Passbook from theft or unauthorized use. Regardless, removing sensitive payment data from the merchants’ hands is a necessary step to solve the increased breach epidemic retailers have been facing.

What’s especially bold is Apple’s move to bypass the payment processors that have been used for decades. POS and online ordering systems integrated to support Apple Pay can send the Device Account Number and the dynamic transaction security code directly to the card issuer for approval. In essence, Apple is creating its own secure payment network to facilitate its proprietary payment technology.

Long history of failure
Unfortunately, adoption will be a significant challenge. If you look at past attempts to change consumer payment behavior, there’s a long list of failures. For example, contactless payments were rolled out on a limited basis by inserting a rice-sized RFID chip in credit cards a purchaser waves in front of the terminal instead of swiping the magnetic stripe. Adoption in the United States was abysmal. More recently, mobile wallet offerings such as Visa payWave used NFC for contactless payments in stores, but gained little traction beyond pilot implementations.

Apple Pay is a strategic move to expand further into the major mobile wallet marketplace to rival PayPal and other contenders. The big question is whether Apple can succeed in convincing consumers and businesses to ditch the plastic. They both need compelling benefits to justify the behavioral changes. For example, Starbucks successfully leveraged its mobile application with payment capabilities to enhance the customer experience and drive its loyalty program.

One way Apple could incentivize adoption is by providing loyalty points for purchases made using Apple Pay, redeemable in the form of Apple Store purchases. Consumers would get rewarded for making the switch while driving increased traffic to the Apple stores. This in turn would generate demand for merchants to support Apple Pay. Finally, by eliminating the payment processors from the transaction flow, retailers would reap greater benefits with lower processing fees and increased cost savings that yield higher profits.

If successful, Apple Pay would cement Apple’s dominance across the user experience and extend its domain to mobile payments where the biggest potential is in the rapid adoption of m-commerce, defined as shopping online from handheld devices. Forrester Research projects m-commerce in the United States to top $293 billion by 2018.

Lucas Zaichkowsky is the Enterprise Defense Architect at AccessData, responsible for providing expert guidance on the topic of cyber security. Prior to joining AccessData, Lucas was a technical engineer at Mandiant where he worked with Fortune 500 organizations, the Defense ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
LucasZa
50%
50%
LucasZa,
User Rank: Moderator
9/15/2014 | 6:32:09 PM
Are we there yet?
Godwin's Law will rear its head in 3...2...1...

Seriously though, the word "hopefully" calls attention to a potential risk factor that lies within secure coding practices and unpublished technical specifications. I researched by digging up everything I could find in the public domain and cross referencing that with my knowledge on the payment processing world from past experience working in multiple job functions at a payment processor.

Getting private details for publication from a highly secretive company would be difficult to say the least. I could have been sneaky by calling contacts, digging up dirt on Apple Pay's implementation and their security development lifecycle adherence track record, then publish a tell-all. But that would be a jerk move. Besides, I have a day job on top of writing articles as a contributing author.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/15/2014 | 6:00:14 PM
Re: Device Account Number
That is clear actually. Once you identify the device and the card and the POS with a unique random number the rest is easy to do. You can store the number as you want and where you want, that will not breach any security rules or regulations.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/15/2014 | 5:55:13 PM
Re: Speaking of security...
I agree. What Apple is doing would eventually be more secure than a plastic credit card. You can always improve security measure on the system, it is more difficult and costly to do that on the physical card.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
9/15/2014 | 5:50:00 PM
No plastic card needed
Thanks for sharing this article, quite informative. I have high hopes in Apple's and other companies' efforts to replace credit cards. We do not really need to have a card with magnetic stripe to secure our money transactions. That is simply failure of banks and credit cards providers and it takes Apple to disrupt the market to go where we needed to be already.
dkoobfhlbc
50%
50%
dkoobfhlbc,
User Rank: Apprentice
9/15/2014 | 2:22:24 PM
Re: The entire article falls apart at "Hopefully"
Congrats - 

 

Here's a million internet points. 

You win at arguing on the internet today. 

Come back again tomorrow for more points!
SDiver
100%
0%
SDiver,
User Rank: Strategist
9/15/2014 | 1:42:04 PM
Re: The entire article falls apart at "Hopefully"
First, I never stated that you were pro-Android.  I used Android only as an example because of its dominance in the market so please learn to read.  Your claim of Apple's wrongdoings as being forgotton is patently false.  I'm actually impressed with Android and have seen its users create some great apps with it.  Competition is good for customers.

Second, Apple is only creating its own payment processor.  Nobody has implied that Apple has "created' a new feature.  As for "revolutionizing" the industry I guess that all depends on how Apple implements this new system and how it will stand up to attack.  I challenge you to show me where the author implied that Apple is creating some new feature other than its own new payment system.  The author's statements are reasonable and is only reporting a new release.  What else should he do?

Third, you're complaining over the word "hopefully?"  Are you serious?!  I completely agree with the author and also hope that Apple really did its homework with this new system rather than rushing to market with a poor implementation.  Apple hasn't released any technical data yet on the new system and I'm sure we'll learn more over time.  If you have more technical detail about this new system then I would be eager to know what you learned. 

Fourth, if your concerns are legitimate then why reference Apple customers as "sheeple?"  Immature, to say the least.  As security professionals we should be helping the general public with solutions; not criticizing them for making decisions we don't like.

Finally, we all have known for a long time that cash is the only payment method where your ID is safe.  Either use cash, plastic or a contactless payment system.  The choice is yours.
dkoobfhlbc
50%
50%
dkoobfhlbc,
User Rank: Apprentice
9/15/2014 | 12:36:57 PM
Re: The entire article falls apart at "Hopefully"
I'm not trying to nitpick at why Apple Pay is completely insecure. What really irks me is that NFC payment has been around for YEARS. Yes its constantly evolving and becoming better and stronger and faster and more secure. What really makes me groan is when Apple 'creates' a feature that the masses think is brand new and 'revolutionary' when they're merely taking a technology they did not invent slapping a pretty face on it and calling it their own. While this is great for the recognition of the technology a wider attack vector means it'll just be the next big thing that is hacked.

 

Furthermore - I was initially upset that the author of this article chose to use the word 'hopefully' when describing the 'greatest technology company in the world's approach to payment security. I would have much rather the author done a little more investigation and added some substance to the article to describe why Apple Pay should be adopted and why it's more secure than other NFC payment vendors.

 

Finally - nowhere in my original comment did I mention I was pro Android/ Goole or Microsoft or Blackberry or any other vendor for that matter. I did not say any other vendor is more secure or has fewer flaws than Apple - I'm just upset that Apple's wrongdoings are so quickly forgotten when they introduce something new and shiny. Why the specific Google hate? Defensive much?

Last I checked - nobody's had their identity stolen, been asked for an ID or had their credit ruined when paying in cash.
SDiver
100%
0%
SDiver,
User Rank: Strategist
9/15/2014 | 12:21:13 PM
Re: The entire article falls apart at "Hopefully"
dkoobfhlbc, your comments provide no useful insight.

Yes, Apple's iCloud was breached but so has Android and Google Wallet.  In fact, name any system that is 100% foolproof so what's your beef with Apple?  Are Android users "sheeple" too or should Google be solely responsible for determining our security needs?

We have yet to see the reliability of Apple's new payment system.  Obviously, this new system will have flaws just like any other system but if you're so concerned about the "sheeple" putting their credit card numbers at risk then I invite you to:  1) please provide detailed information WHY Apple Pay is so weak; and 2) name the perfect payment system that you have obviously discovered which the rest of us have missed.
LucasZa
50%
50%
LucasZa,
User Rank: Moderator
9/12/2014 | 4:02:08 PM
Speaking of security...
I agree with those concerned about security flaws. It is possible that someone could figure out a way to retrieve the stored card data from the Secure Element chip. Passbook uses an iOS API to access that chip. If there's a weakness in protecting that API, then that could lead to apps being deployed to the Apple store that steal stored cards or malicious websites that use another vulnerability to gain initial access (e.g. jailbreaking techniques), then exploit the API flaw to steal card data. Or perhaps there's a way criminals could conduct fraud if they get on Apple's servers relaying transaction data. What if they managed to get the seed data used to generate the unique transaction identifiers? Lots of possibilities.

I also agree with those that state it's still more secure than using magstripe or EMV. Nothing is perfectly secure, so choosing the option with the least attack surface area makes sense. Unfortunately, most people don't care enough about security to ditch the plastic. They need some sort of gratification to change behavior.
LucasZa
50%
50%
LucasZa,
User Rank: Moderator
9/12/2014 | 3:52:06 PM
Re: Device Account Number
Marilyn, the Device Account Number is a permanent unique identifier for the mobile device. I'm not sure if it's randomly generated or derived from seed data. Either way, that Device Account Number gets stored on the "Secure Element" chip they've added to the iPhone 6. This is their way of implementing the Secured Element part of the NFC specification. More info at www.smartcardalliance.org/publications-nfc-frequently-asked-questions/#7

When it comes time to pay, the iPhone 6 will use NFC to transmit the Device Account Number and a a unique transaction identifier to the POS using those contactless readers that nobody in America currently cares about. This is where it gets a little vague. Prior reports talked about the elimination of the payment processor middleman. The merchant POS has to send the transaction data somewhere though. So I'd assume they're sending it through Apple servers which then authenticate the transaction with the card issuing bank before processing it through the appropriate card brand network such as Visa. Think of the transaction identifier as being an out of band mechanism so criminals can't leverage stolen data from Apple Pay transactions since they'd need another transaction identifier. I'm guessing the transaction identifiers are generated similar to how Google Authenticator and RSA two-factor have a rolling code that's constantly in sync with the server.

My guess that Apple is in the middle relaying transaction data stems from their careful choice in wording when they state they "don't save" your transaction data. They're choosing their words carefully to hide the complex inner workings behind a simpler message that doesn't require niche payment processing knowledge.
Page 1 / 2   >   >>
10 Ways to Keep a Rogue RasPi From Wrecking Your Network
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/10/2019
The Security of Cloud Applications
Hillel Solow, CTO and Co-founder, Protego,  7/11/2019
Where Businesses Waste Endpoint Security Budgets
Kelly Sheridan, Staff Editor, Dark Reading,  7/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Jim, stop pretending you're drowning in tickets."
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-13623
PUBLISHED: 2019-07-17
In NSA Ghidra through 9.0.4, path traversal can occur in RestoreTask.java (from the package ghidra.app.plugin.core.archive) via an archive with an executable file that has an initial ../ in its filename. This allows attackers to overwrite arbitrary files in scenarios where an intermediate analysis r...
CVE-2019-13624
PUBLISHED: 2019-07-17
In ONOS 1.15.0, apps/yang/web/src/main/java/org/onosproject/yang/web/YangWebResource.java mishandles backquote characters within strings that can be used in a shell command.
CVE-2019-13625
PUBLISHED: 2019-07-17
NSA Ghidra before 9.0.1 allows XXE when a project is opened or restored, or a tool is imported, as demonstrated by a project.prp file.
CVE-2019-3571
PUBLISHED: 2019-07-16
An input validation issue affected WhatsApp Desktop versions prior to 0.3.3793 which allows malicious clients to send files to users that would be displayed with a wrong extension.
CVE-2019-6160
PUBLISHED: 2019-07-16
A vulnerability in various versions of Iomega and LenovoEMC NAS products could allow an unauthenticated user to access files on NAS shares via the API.