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
Careers and People
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
“Contactless” HCE Payments Promise Simplicity But Is It Secure?
Newest First  |  Oldest First  |  Threaded View
pcarrollvs
pcarrollvs,
 User Rank: Author
9/5/2014 | 12:02:49 PM
Re: SecureKey Briidge.net Connect
Hello JoshuaR663. I don't know enough about SecureKey Bridge.net Connect to offer an opinion, and this would probably not be the right forum in any event :)

You mention the subject of Tokenization and you are correct that we can expect to see Tokenization being implemented alongside not just HCE but also EMV. However it's worth remembering that a primary objective of tokenization is to eliminate the need for sensitive card data to be stored at the merchant side. It can't prevent cards being cloned (skimmed) and doesn't add any additional validation on the legitimacy of the transaction. The card data still needs to be stored (by the processor/tokenization provider) and held for merchant payment purposes (matching of token with card data) at settlement.

Whilst tokenization is definitely a step forward as it does reduce sensitive payment data proliferation, there are a number of issues that are recognised by the industry. I intend to write a more detailed note on the subject of Tokenization in the near future. 
aws0513
aws0513,
 User Rank: Ninja
9/4/2014 | 11:53:25 AM
Re: Just a silly thought > fuzzy math of fraud
As Pat related, it is very difficult to identify how risk acceptance of fraud is implement within the financial industry.  I am sure there are documented formulas out there, but nobody seems to be willing to share that information readily.  Less so try to explain the reasoning behind the formulas.

My silly idea was basically because of this fact.  From all that I have encountered and observed, the financial industry has already accepted risk before they even begin to hand out money.  So all of the repercussions that could be developed in terms of fines and/or administrative action would also be rolled into that equation.

So why not make it profitable for someone to mitigate risk right out of the gate?  Establish a model where the governance body behind a security control that is widely implemented can actually benefit if the solution they provide is proven to have a high amount of risk mitigation while still providing a reasonable user experience.  I have a feeling that if this is done, there may be a huge opportunity for a governance body and a technology solution.

And that is the challenge...  the reasonable user experience.

Many financial organizations seem to view security controls as a barrier to obtaining new business.  This of course is partially due to public disdain for those activities that seem combersome or complicated...  and I get that.  But the other side of this equation is due to the rampant pressure for financial organizations to generate business... to make money while accepting a certain level of risk. 
To me it is like trying to prevent teens from engaging in sex.  The hormonal pressures are enormous.  Both sides of the equation want what the other has...  greatly.

 

 
pcarrollvs
pcarrollvs,
 User Rank: Author
9/3/2014 | 7:15:45 PM
Re: Just a silly thought > fuzzy math of fraud
Hi Marilyn, trying to get a handle on the true cost of fraud in any industry segement is notoriously difficult. Mention fraud losses to any financial institution and it's as though you have said a bad word... The industry is paranoid about the reputational damage that could ensue, and makes a concerted effort to downplay the impact on their institution. The problem is that unless you can measure it, you can't manage it. And measurement is all about understanding and knowledge. It the industry can't own up to its failings, what chance is there of solving the problem? In terms of your specific question, in the recent past some good studies have been carried out by research companies that have helped quantity the question around the true cost of fraud, and have highlighted that with card present fraud (eg ATM/POS), actual fraud losses make up about 30% of the total cost of fraud, whilst with card not present fraud (eg online), actual fraud losses make up approx 25% of the total cost of fraud.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
9/3/2014 | 9:21:47 AM
Re: Just a silly thought > fuzzy math of fraud
Thanks, Pat. What you say makes perfect sense to me. Are there any industry estimates about how off the mark organizations are in their estimates of the true costs of fraud? For example, are they in the ball park of  2x higher? Does it depend on the industry? 
pcarrollvs
pcarrollvs,
 User Rank: Author
9/3/2014 | 9:06:41 AM
Re: Just a silly thought > fuzzy math of fraud
It's an unfortunate fact Marilyn, and not without reason. Establishing the true cost of fraud to an organization is a complex process that spans many departments, since it's not just fraud losses that need to be taken into account, but also the cost of investigation and administration of fraud. Fraud can also affect legal fees and regulatory and compliance budgets, IT and Security as well, although in many cases it's highly likely that such costs are not classified as "fraud" in the budget, for obvious reasons. Not alone does this make the true cost of fraud to an organization difficult to calculate, but it also means that fraud costs may be under-reported as a consequence and create a misleading impression as to the level of fraud in any market. The implication of all of this is that it's ultimately only the fraudsters that benefit and the shocking truth is that it is the industry that is unwittingly assisting them. I believe that it is time for the relevant governing bodies to stand up and be counted. The only losers will be the fraudsters.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
9/3/2014 | 7:58:10 AM
Re: Just a silly thought > fuzzy math of fraud
Interesting point about tying together the cost of fraud and the cost of a fraud solution. It seems like such an obvious connection. Are organizations really so balkanized that they can't put these basic facts together?
pcarrollvs
pcarrollvs,
 User Rank: Author
9/3/2014 | 6:03:34 AM
Re: Just a silly thought
You raise a very interesting point aws0513. It's quite amazing that in today's world we actually budget for fraud! What incentive is there to get rid of fraud when it's in the budget? I like your value proposition, ie make good security profitable. The sad fact is that every one of us pay the price of poor security when we use our payment cards or our mobile at the checkout. And it's a significant cost indeed, as high as 160 basis points (1.6%) of the transaction value (and in some cases even higher). It's even sadder to know that that the technology exists today to virtually eliminate fraud at the checkout due to the ability to accurately place the legitimate cardholder/mobile user at the place of the transaction, in real-time, but in a totally privacy sensitive manner, yet there is reluctance by the industry to adopt/deploy such technologies. The big problem is that in big organizations, the silo effect kicks in, and the folk who budget for fraud are not aligned with with the division who could implement such technology, and unless you can reliably aggregate cost of fraud and cost of solution, the business value proposition becomes blurred. I for one would love to see the governing bodies take more action to force the industry to deploy such solutions, afterall, it is in all our interests, and the only individuals to benefit from industry procrastination are the fraudsters!
aws0513
aws0513,
 User Rank: Ninja
9/2/2014 | 2:21:31 PM
Just a silly thought
As I was reading this article, I began to wonder if things would change if the governance bodies behind HCE and/or SE technologies standards were to be billed for any transactions where non-repudiation could not be fully established.

The silly model in my head is for every transaction, the governance body would get a small cut (the carrot).  But for every proven false transaction, the governance body would pay the full remediation cost for the transaction (the stick).  In other words, make good security profitable, but risk of fraud seem unpalatable to the organization responsible for validating the standard.

At the same time, allow the governance body to bill/fine those vendors that implement the technology standard in a manner that introduces vulnerabilities.

I know...  just plain silly.  Maybe I need to get another caffiene drink.

Good article, but I fear the industry till adopt HCE with the attitude that "What worse could happen compared to the current card based system?"
JoshuaR663
JoshuaR663,
 User Rank: Apprentice
9/2/2014 | 1:40:58 PM
SecureKey Briidge.net Connect
Is this technology (utilizing tokenization, it seems) a true viable option to secure HCE, even on a rooted phone? I see tokenization being part of the answer if it is done at the vendor/bank level, but I'm not sure how or where in the process SecureKey tokenizes data. Thoughts?


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-33196
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
CVE-2023-33185
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
CVE-2023-33187
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
CVE-2023-33194
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
CVE-2023-2879
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file