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.

Endpoint //

Authentication

9/10/2014
06:11 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Apple Pay Ups Payment Security But PoS Threats Remain

Apple's new contactless payment tech will not stop point-of-sale breaches like Home Depot and UPS, but it could make those breaches less valuable to attackers.

Yesterday, Apple announced, to much fanfare, details on its upcoming iPhone 6 and Apple Watch, including that the new devices will be equipped with Apple Pay -- a contactless mobile payment scheme that allows users to make purchases at points of sale with their phones and, more importantly, never communicates their credit card data to the retailer.

Apple Pay will not prevent malware attacks on point-of-sale terminals. It won't stop Backoff from breaching UPS or BlackPOS from breaching Home Depot. What it will do is make the data on those PoS terminals less valuable to attackers.

It also shifts most of the responsibility for payment security off of retailers themselves, and onto Apple.

How it works
As Apple explains:

With Apple Pay, instead of using your actual credit and debit card numbers when you add your card, a unique Device Account Number is assigned, encrypted, and securely stored in the Secure Element, a dedicated chip in iPhone and Apple Watch. These numbers are never stored on Apple servers.

In other words, the only point of failure is on the card-holder's mobile device, not on an Apple server that could be targeted by attackers. (Of course, Apple currently possesses payment card data for iTunes and App Store customers who voluntarily asked Apple to store that data.)

Also:

And when you make a purchase, the Device Account Number alongside a transaction-specific dynamic security code is used to process your payment. So your actual credit or debit card numbers are never shared with merchants or transmitted with payment.

In other words, Apple Pay has "tokenized" payment and turned your Apple device into a mini point-of-sale system.

"That's where the wallet opens -- on the device," says Lev Lesokhin, executive vice president of CAST Software. "That makes the authentication an Apple problem, not a [retail store] problem... If [credit card numbers are] what [attackers] want, they're going to have to go after Apple."

Instead of authenticating to a PoS terminal (with a credit card and a PIN number), you authenticate to the Apple device. If you use both a passcode and a fingerprint to secure your device, then every purchase you make uses the authentication trifecta: something you know (the passcode), something you have (the device), and something you are (the fingerprint).

That ultimately makes the Apple device far more important to a customer than the PoS terminal. Plus it gives the customer more control over their own security -- if the device is stolen, all this information could be deleted using remote data wipe.

Even if an attacker uses malware to compromise a store's PoS terminal and take all its data, that data will not include credit card numbers, just tokens from Apple Pay -- which are basically one-time tokens, since they all include transaction-specific codes.

How will attackers adjust?
If retailers no longer require credit card numbers to process payments, just tokens, then attackers won't necessarily need credit card numbers to make purchases either; they just need tokens. So the next questions are: can attackers use those tokens they nabbed from PoS systems just like they would use credit card numbers? Can those tokens be spoofed?

In the short term, the answer is probably no. However, security experts point out that attackers won't give up so easily.

For example, Lesokhin wonders, instead of using malware that compromises point-of-sale systems, attackers may instead create software that can spoof a user's whole iPhone -- fingerprint included. (After all, biometric scanners turn your body into a data file. An attacker doesn't necessarily need your finger; he just needs a way to steal, then input that data.)

There are also questions about what happens outside the interaction between the Apple device and the PoS terminal -- and the answers may vary from merchant to merchant.

"It really depends on the implementation," says Armando Orozco, senior malware intelligence analyst at Malwarebytes Labs. "If no credit card data is passed there's nothing for the malware to capture. So, in theory, Apple Pay users would not have been compromised by the Backoff malware."

Joe Schumacher, senior security consultant at Neohapsis Labs, points out that payment card data may still be communicated, just not in the traditional way.

"For example, we do not know if the store would be sent the credit card number on a different virtual channel and/or if the merchant/store would store this credit or debit card number in their environment or rely on a token to represent the sale or transaction," says Schumacher. "From the information released by Apple and Google, it appears that the merchant/store does not receive the sensitive information over the NFC medium; we do not know if the merchant/store receives the sensitive information through another channel or if Apple/Google will be sending the funds to the merchant/store bank/processor."

From magnetic stripe to NFC
Apple Pay may be just the thing that finally persuades American retailers to move away from magnetic stripe technology to NFC. While NFC (as well as Chip-and-PIN) has been championed as a big security improvement to magnetic stripe, it still doesn't eliminate the problem of malware that goes after point-of-sale systems.

As Chris Strand, Senior Director of Compliance at Bit9, says, "At the end of the day, what's the difference" between magnetic stripe and NFC? "It's a different channel, but I'm still transferring my data into that PoS terminal."

Strand also cautions retailers against focusing too much on the customer-facing side of the transaction. If retailers think that all their problems will be solved by the front-end of purchases, they may get distracted from securing the back-end. "And attackers love distractions," he says.

These caveats aside, security experts are praising Apple -- not just for Apple Pay itself, but for emphasizing the need for multi-factor authentication.

"The more significant announcement," says John Gunn, vice-president of corporate communications for VASCO, "was on Sep. 5 when Tim Cook announced that Apple would step up its security game by broadening its use of two-factor authentication and more aggressively encouraging people to turn on two-factor authentication. When the most influential company in the industry comes out with a strong endorsement of two-factor authentication, that's good news for consumers and bad news for hackers."

Apple Pay will be available on iPhone 6 or Apple Watch, and will be usable at over 220,000 stores accepting contactless payments.

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
msspotlight
50%
50%
msspotlight,
User Rank: Apprentice
10/7/2014 | 12:40:53 PM
TIMA hardware chip?
My question is this....is the HW chip where the token is stored TIMA?
msspotlight
50%
50%
msspotlight,
User Rank: Apprentice
10/7/2014 | 12:35:40 PM
Re: Note quite 3-factor authentication ...
It depends on the encryption algorithm. If it is say for example AES 256 it would take years to crack not to mention they would have to physically have your device which if this was the case you know it's gone and can call your CC company and cancel the card.
Technocrati
50%
50%
Technocrati,
User Rank: Ninja
9/18/2014 | 5:11:09 AM
Re: Apple creates De Facto Standard ?

@Sara     Welcome back !   I see.  Well, I really enjoyed the topic - I was initially very curious as to how Apple plans to address this potential security nightmare.

But after discussions with my peers along this thread and of course your work - I have a better understanding of just how Apple plans to pull this off.

Sara Peters
50%
50%
Sara Peters,
User Rank: Author
9/16/2014 | 2:01:38 PM
Re: Note quite 3-factor authentication ...
@GonzSTL  I completely agree with you on this:  "Why not just make two-factor authentication required for using Apple Pay?" They could prompt users for both a fingerprint and a password even if the device isn't locked at the time that they make a purchase.
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
9/16/2014 | 1:59:07 PM
Re: Apple creates De Facto Standard ?
@Technocrati   Geez, a girl goes on vacation a couple days and you all have a great conversation without me. Thanks for that! 

As to your comment, I find this a fascinating thought: "Who's regulating this? Seems to me Apple just created a de facto standard ?"

I imagine that the PCI Council will have something to say on it as well, and they're probably still making up their minds about it. The near-field communications part isn't the important thing; it's the authentication. 
teck
50%
50%
teck,
User Rank: Apprentice
9/15/2014 | 9:39:58 PM
A few errors in this article
Payment authorization does not require PIN + fingerprint.  The default is fingerprint scan, if that fails a certain number of times (not able to presently disclose) it reverts to PIN.

Apple does not possess the ability to convert a token into its full credit card representation.  Rather that is the role of a TSP (Token Service Provider).  Currently each PNO (AMEX, Visa, M/C) operates its own TSP and thus only they are able to detokenize a token back to the actual credit card data.
Technocrati
50%
50%
Technocrati,
User Rank: Ninja
9/13/2014 | 1:58:26 AM
Re: Apple creates De Facto Standard ?

@GAProgrammer   Interesting.  I had not thought about PayPal, and I think you are right - Apple would love to have a large piece of this market.

Technocrati
50%
50%
Technocrati,
User Rank: Ninja
9/13/2014 | 1:54:29 AM
Re: Note quite 3-factor authentication ...

@GonzSTL    I certainly appreciate your level headed approach to this difficult issue.   I often get the feeling that NFC is a technology that even though the consumer is cool towards the idea, these manufacturers are dying to implement it.

 

I guess the real goal is to make the phone a tool for real-time commercial transactions, but people don't seem to be too excited about it, the uses we have now seem to be more than adequate.  

And I agree, I hope the industry regulates itself but the first thing they probably need to do is to come to grips with the fact that not many want NFC and even if it is forced upon the consumer - they have choices now.

 

I think Apple just might learn this lesson again. 

Technocrati
50%
50%
Technocrati,
User Rank: Ninja
9/13/2014 | 1:46:22 AM
Re: Apple creates De Facto Standard ?

"....More and more of my friends who use iPhones are finding that the device REALLY isn't that great. I know of 10 people in the past 3 months who have ditched theirs for Samsung phones."

 

@GAProgrammer     That is really interesting to hear.  I have noticed this myself - Many  iPhone users don't seem to be as happy as they once were.  It has been a long time since Apple has had a significant new offering and when they did - they went larger, which is just what their competition ( Samsung ) has been doing for years.

Technocrati
50%
50%
Technocrati,
User Rank: Ninja
9/13/2014 | 1:34:51 AM
Re: Note quite 3-factor authentication ...

@Some Guy    I see.   Yes the enabling and the disabling of the service is easy and I think that is the case for phones that have NFC, but there has got to be a better way to transmit the signal.  

Of course I am at a loss for the answer to this plea but we will see if Apple can make this process sexy enough for mass adoption. 

Page 1 / 3   >   >>
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8904
PUBLISHED: 2020-08-12
An arbitrary memory overwrite vulnerability in the trusted memory of Asylo exists in versions prior to 0.6.0. As the ecall_restore function fails to validate the range of the output_len pointer, an attacker can manipulate the tmp_output_len value and write to an arbitrary location in the trusted (en...
CVE-2020-8905
PUBLISHED: 2020-08-12
A buffer length validation vulnerability in Asylo versions prior to 0.6.0 allows an attacker to read data they should not have access to. The 'enc_untrusted_recvfrom' function generates a return value which is deserialized by 'MessageReader', and copied into three different 'extents'. The length of ...
CVE-2020-12106
PUBLISHED: 2020-08-12
The Web portal of the WiFi module of VPNCrypt M10 2.6.5 allows unauthenticated users to send HTTP POST request to several critical Administrative functions such as, changing credentials of the Administrator account or connect the product to a rogue access point.
CVE-2020-12107
PUBLISHED: 2020-08-12
The Web portal of the WiFi module of VPNCrypt M10 2.6.5 allows command injection via a text field, which allow full control over this module's Operating System.
CVE-2020-7374
PUBLISHED: 2020-08-12
Documalis Free PDF Editor version 5.7.2.26 and Documalis Free PDF Scanner version 5.7.2.122 do not appropriately validate the contents of JPEG images contained within a PDF. Attackers can exploit this vulnerability to trigger a buffer overflow on the stack and gain remote code execution as the user ...