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

2/24/2015
01:00 PM
Sara Peters
Sara Peters
Slideshows
Connect Directly
Twitter
RSS
E-Mail

7 Things You Should Know About Secure Payment Technology

Despite the existence of EMV and Apple Pay, we're a long way from true payment security, especially in the US.
4 of 8

EMV Doesn't Solve Everything
'Monopoly Money [Explored],' by Jason Devaun

As Litan explains, attackers are finding ways around EMV. Part of the reason they're able to do it is that card issuers relax their fraud protection controls on EMV purchases.

She provides the example of a group of attackers in Brazil who were able to complete fake EMV transactions using stolen magstripe data. As she explained in a recent report:

They took the stolen card data and attached to it dummy cryptograms and dummy one-time codes that are part of EMV card transaction sets, and successfully transmitted payment authorization requests over payment processing networks to EMV and non-EMV card issuers across the globe. These fraudulent transactions were subsequently authorized and settled, and the fraud scheme succeeded against non-EMV (only magstripe) U.S. card issuers and EMV card issuers in different countries.

EMV card issuers outside the U.S. authorized these fraudulent EMV transactions because their controls simply looked for the EMV transaction indicator, which was enough for their authorization systems to approve the card payment request. The EMV issuers were caught off guard because they had not implemented 'handshakes' for the transaction's EMV cryptograms and one-time codes.

'They relaxed fraud controls,' says Litan, 'so they got caught with their pants down.'

Attackers targeting Home Depot stores in Canada found another way around EMV, leveraging the fact that PoS terminals have to accept both EMV and magnetic stripe cards. They infected point-of-sale terminals with malware that social-engineered shoppers. The PoS would simply prompt customers to swipe their cards -- even if they had EMV-equipped cards. They'd lift the magstripe data, then complete the transaction through the EMV chip.

Even when tokenization technology is added to the mix, Litan explains that malware authors can steal the magstripe data before it's tokenized. The only way to prevent that is by implementing point-to-point encryption (P2PE).

'P2PE is really what the retailers are focused on,' says Litan, but unfortunately most P2PE solutions have not yet been PCI-certified, so some retailers are hesitant to deploy them. Merchants get some breaks on their PCI audits if they use P2PE, but only if they use PCI-certified P2PE applications.
"Monopoly Money [Explored]," by Jason Devaun

As Litan explains, attackers are finding ways around EMV. Part of the reason they're able to do it is that card issuers relax their fraud protection controls on EMV purchases.

She provides the example of a group of attackers in Brazil who were able to complete fake EMV transactions using stolen magstripe data. As she explained in a recent report:

They took the stolen card data and attached to it dummy cryptograms and dummy one-time codes that are part of EMV card transaction sets, and successfully transmitted payment authorization requests over payment processing networks to EMV and non-EMV card issuers across the globe. These fraudulent transactions were subsequently authorized and settled, and the fraud scheme succeeded against non-EMV (only magstripe) U.S. card issuers and EMV card issuers in different countries.

EMV card issuers outside the U.S. authorized these fraudulent EMV transactions because their controls simply looked for the EMV transaction indicator, which was enough for their authorization systems to approve the card payment request. The EMV issuers were caught off guard because they had not implemented "handshakes" for the transaction's EMV cryptograms and one-time codes.

"They relaxed fraud controls," says Litan, "so they got caught with their pants down."

Attackers targeting Home Depot stores in Canada found another way around EMV, leveraging the fact that PoS terminals have to accept both EMV and magnetic stripe cards. They infected point-of-sale terminals with malware that social-engineered shoppers. The PoS would simply prompt customers to swipe their cards -- even if they had EMV-equipped cards. They'd lift the magstripe data, then complete the transaction through the EMV chip.

Even when tokenization technology is added to the mix, Litan explains that malware authors can steal the magstripe data before it's tokenized. The only way to prevent that is by implementing point-to-point encryption (P2PE).

"P2PE is really what the retailers are focused on," says Litan, but unfortunately most P2PE solutions have not yet been PCI-certified, so some retailers are hesitant to deploy them. Merchants get some breaks on their PCI audits if they use P2PE, but only if they use PCI-certified P2PE applications.

4 of 8
Comment  | 
Print  | 
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
macker490
50%
50%
macker490,
User Rank: Ninja
2/27/2015 | 9:11:08 AM
Let's get it right
Fixing the Point of Sale Terminal (POST)

THINK: when you use your card: you are NOT authorizing ONE transaction: you are giving the merchant INDEFINITE UNRESTRICTED access to your account.

if the merchant is hacked the card numbers are then sold on the black market. hackers then prepare bogus cards -- with real customer numbers -- and then send "mules" out to purchase high value items -- that can be resold

it's a rough way to scam cash and the "mules" are most likely to get caught -- not the hackers who compromised the merchants' systems .


The POST will need to be re-designed to accept customer "Smart Cards"

The Customer Smart Card will need an on-board processor, -- with PGP

When the customer presents the card it DOES NOT send the customer's card number to the POST.  Instead, the POST will submit an INVOICE to the customer's card.  On customer approval the customer's card will encrypt the invoice together with authorization for payment to the PCI ( Payment Card Industry Card Service Center ) for processing and forward the cipher text to the POST

Neither the POST nor the merchant's computer can read the authorizing message because it is PGP encrypted for the PCI service.  Therefore the merchant's POST must forward the authorizing message cipher text to the PCI service center.

On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer's account to the merchant's account.

The POST will then print the PAID invoice.  The customer picks up the merchandise and the transaction is complete.

The merchant never knows who the customer was: the merchant never has ANY of the customer's PII data.

Cards are NOT updated.  They are DISPOSABLE and are replaced at least once a year -- when the PGP signatures are set to expire.  Note that PGP signatures can also be REVOKED if the card is lost.

Transactions are Serialized using a Transaction Number ( like a check number ) plus date and time of origination.    This to prevent re-use of transactions.   A transaction authorizes one payment only not a cash flow.

EMV is no solution: and EMV card passes the cardholders account number, name, expiration date, et al
to the POST in plain text -- making the same error that the mag stripe reader makes and which
has been heavilly exploited by criminals.

~~~

Sara Peters
50%
50%
Sara Peters,
User Rank: Author
2/26/2015 | 9:17:47 AM
Re: How Much Clout Does Apple Have?
@Dr. T  "Google will most likely capture big part of the secure payment market in my view." I can see that happening, but I'm not sure when or how. Google Wallet hasn't accomplished much. Maybe as more Android phones add fingerprint scanners, Google will make a bigger play in the secure payment space.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
2/25/2015 | 9:04:13 PM
Re: How Much Clout Does Apple Have?
Agree. Apple will always do it in their own ways and generally different from the rest. That is good and bad. We always need interoperability between systems but we also want Apple ways. :--))
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
2/25/2015 | 8:59:25 PM
Re: How Much Clout Does Apple Have?
Agree. Apple simple says I do not know anything about you, if that is true, then we have the right implementation in Apple Pay, they do not need to know anything about us.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
2/25/2015 | 8:56:34 PM
Re: How Much Clout Does Apple Have?
I agree. Google wallet has been around for long time but they failed to engage big banks and other financial institutes. Obviously Apple noticed that and started with right course of actions.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
2/25/2015 | 8:53:19 PM
Re: How Much Clout Does Apple Have?
Apple has a good chance with Apple payment where iPhone is being used, Google will most likely capture big part of the secure payment market in my view.
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
2/25/2015 | 8:51:18 PM
Right direction
We have been hearing a lot on secure payment systems recently, this is a good news, and there are good opportunities for small and big companies such as Apple, Google, Samsung. It is actually very late but very important for us to switch this new trend.
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
2/25/2015 | 7:11:19 PM
Re: How Much Clout Does Apple Have?
Thanks for the update, Tom!
Thomas Claburn
50%
50%
Thomas Claburn,
User Rank: Ninja
2/25/2015 | 3:42:34 PM
Re: How Much Clout Does Apple Have?
> they may not like letting Apple insert itself so closely into the customer relationship.

As I understand it, Apple Pay does not interfere at all with that relationship -- Apple designed its system so the transaction remains known to the merchant and buyer, but not to Apple. Had it done otherwise, companies would have been far more wary.
Sara Peters
50%
50%
Sara Peters,
User Rank: Author
2/25/2015 | 11:26:46 AM
Re: How Much Clout Does Apple Have?
@Drew "Regarding tokenization, I'm guessing whichever road Apple goes down becomes a de facto standard." I think you're right, and it doesn't hurt that Apple already built Apple Pay on an existing standard.
Page 1 / 2   >   >>
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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-10133
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.
CVE-2019-10134
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded.
CVE-2019-10154
PUBLISHED: 2019-06-26
A flaw was found in Moodle before versions 3.7, 3.6.4. A web service fetching messages was not restricted to the current user's conversations.
CVE-2019-9039
PUBLISHED: 2019-06-26
The Couchbase Sync Gateway 2.1.2 in combination with a Couchbase Server is affected by a previously undisclosed N1QL-injection vulnerability in the REST API. An attacker with access to the public REST API can insert additional N1QL statements through the parameters ?startkey? and ?endkey? of the ?_a...
CVE-2018-20846
PUBLISHED: 2019-06-26
Out-of-bounds accesses in the functions pi_next_lrcp, pi_next_rlcp, pi_next_rpcl, pi_next_pcrl, pi_next_rpcl, and pi_next_cprl in openmj2/pi.c in OpenJPEG through 2.3.0 allow remote attackers to cause a denial of service (application crash).