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.

Database Security
Authentication
Mobile
Privacy
Compliance
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
Target Breach: Why Smartcards Won’t Stop Hackers
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
Mathew
50%
50%
Mathew,
 User Rank: Apprentice
1/31/2014 | 4:44:47 AM
Re: Smartcards are unnecessary. This is the Solution

Mark, that sounds like a very innovative approach. In fact, a version of that system is in use in Europe for online purchases. For every given card, the cardholder registers a password. As part of the payment process, they're then asked to provide the 1st, 3rd, and 6th (or some other combo randomly chosen by the card provider's system) letters of their password, to verify the purchase.

But can you imagine if this was introduced at POS terminals? I'd expect to see waiting times multiply. It also wouldn't work for anyone with vision problems. Related customer-service calls to card issuers would skyrocket. Unfortunately, I don't see the approach you outline being simple enough to succeed.

Joe Stanganelli
50%
50%
Joe Stanganelli,
 User Rank: Ninja
1/30/2014 | 11:48:25 PM
Re: Smartcards are unnecessary. This is the Solution
This is why I try to pay with cash whenever possible.  So much easier, so much more secure.  (Indeed, the one time I went shopping at a Target during the affected period, I paid with cash; I'm now VERY glad that I did.)
Joe Stanganelli
50%
50%
Joe Stanganelli,
 User Rank: Ninja
1/30/2014 | 11:45:56 PM
EMV
Another problem with the security of EMV chips is that banks/credit card companies are so delusionally convinced that EMV is imperviously secure that when theft and fraud have occurred, they have given customers who have suffered from ID theft very difficult times, refusing to accept that the fraud occurred without exceptional evidence.
Lorna Garey
50%
50%
Lorna Garey,
 User Rank: Ninja
1/28/2014 | 12:04:20 PM
Re: Smartcards are unnecessary. This is the Solution
One problem is that the share of purchases made in person with the card in hand is shrinking, or at least coming even with ecommerce. Maybe one answer will incorporate smartphones -- a two-factor method, something you have (the chipped card) and something you know (a one-time-use code sent to your phone to verify the purchase).

However, let's remember that the card issuers really, really want to end fraud because they're the ones on the hook. Meanwhile, as a customer, what's the worst that happens if someone in Russia buys an Olympic tee shirt with my card? I call the issuer to have it removed. So, customers won't tolerate inconvenience; there's no percentage in it.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
1/28/2014 | 11:36:56 AM
Re: Smartcards are unnecessary. This is the Solution
Not prepared to conceded that smart cards are unncessary. In fact I was gratified to read in a Dallas business news story that Wal-Mart and Kroger already have checkout systems that work with smart cards that are widely used internationally. Too bad Target customers didn't have that option. I don't suspect too many Wal-Mart or Kroger shoppers do either. 
MarkS229
50%
50%
MarkS229,
 User Rank: Apprentice
1/27/2014 | 9:21:36 PM
Smartcards are unnecessary. This is the Solution
Since this is the only solution guaranteed to solve the credit card/retailer problem, without causing major system redesigns and disruptions, I'll explain it in detail.

First, the credit card companies give everyone a UserID, which gets put on the credit card, instead of the number.

Next, everyone chooses a keyword, like 'NeimanMarcus' or 'Target' (too soon?).

The POS system connects to the credit card company, as usual but, instead of prompting for a password, it displays a matrix of upper/lowercase alphabets, with a random pattern of 1's and 0's underneath.

The user types the 1's and 0's corresponding to his keyword, which goes to the credit card company for approval. After limit checks, expiry checks etc, the user is approved.

The next time the user makes a purchase, the pattern of 1's and 0's is completely different, so the previously typed code is useless to an attacker. Doesn't matter whether it's malware, network snoopers, or spy cameras, the information is always useless.

For obvious reasons, anything in the retailer's logs is also totally useless.

Now, isn't that easier than redesigning the whole system, adding encryption and buying EMV cards?
jagibbons
50%
50%
jagibbons,
 User Rank: Strategist
1/27/2014 | 9:10:05 PM
Re: Smart cards won't stop hackers - but they remove the incentive
The disposable card numbers are really only for online use. You are correct, though, that the retail industry needs better POS security and protection.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
1/27/2014 | 3:50:26 PM
Re: Smart cards won't stop hackers - but they remove the incentive
Thanks, @jagibbons. Sounds like a reasonable option, though I think a better solution would be for the retail industry needs to be pushed to make more of an investment in smart cards and smart POS terminals.
jagibbons
50%
50%
jagibbons,
 User Rank: Strategist
1/27/2014 | 10:33:33 AM
Re: Smart cards won't stop hackers - but they remove the incentive
Our bank, Huntington, provides them. They are actually debit cards connected to a checking account. We can use it once or multiple times. It is possible to get new ones. Some of card brands also offer this service.

It's not a big issue if the card number is invalidated after the transaction when it is skimmed.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
1/27/2014 | 10:24:17 AM
Re: Smart cards won't stop hackers - but they remove the incentive
@jagibbons. I don't think I'm familiar with the one-time use credit cards you refer to. How prevalent are they and who issues them? Banks, retailers or both. 
Page 1 / 3   >   >>


Cybersecurity Industry: It's Time to Stop the Victim Blame Game
Jessica Smith, Senior Vice President, The Crypsis Group,  2/25/2020
Google Adds More Security Features Via Chronicle Division
Robert Lemos, Contributing Writer,  2/25/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9431
PUBLISHED: 2020-02-27
In Wireshark 3.2.0 to 3.2.1, 3.0.0 to 3.0.8, and 2.6.0 to 2.6.14, the LTE RRC dissector could leak memory. This was addressed in epan/dissectors/packet-lte-rrc.c by adjusting certain append operations.
CVE-2020-9432
PUBLISHED: 2020-02-27
openssl_x509_check_host in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-9433
PUBLISHED: 2020-02-27
openssl_x509_check_email in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-9434
PUBLISHED: 2020-02-27
openssl_x509_check_ip_asc in lua-openssl 0.7.7-1 mishandles X.509 certificate validation because it uses lua_pushboolean for certain non-boolean return values.
CVE-2020-6383
PUBLISHED: 2020-02-27
Type confusion in V8 in Google Chrome prior to 80.0.3987.116 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.