Guessing Credit Card Security Details

Researchers have found that they can guess various credit-card-number security details by spreading their guesses around multiple websites so as not to trigger any alarms.

From a news article:

Mohammed Ali, a PhD student at the university's School of Computing Science, said: "This sort of attack exploits two weaknesses that on their own are not too severe but when used together, present a serious risk to the whole payment system.

"Firstly, the current online payment system does not detect multiple invalid payment requests from different websites.

"This allows unlimited guesses on each card data field, using up to the allowed number of attempts -- typically 10 or 20 guesses -- on each website.

"Secondly, different websites ask for different variations in the card data fields to validate an online purchase. This means it's quite easy to build up the information and piece it together like a jigsaw.

"The unlimited guesses, when combined with the variations in the payment data fields make it frighteningly easy for attackers to generate all the card details one field at a time.

"Each generated card field can be used in succession to generate the next field and so on. If the hits are spread across enough websites then a positive response to each question can be received within two seconds -- just like any online payment.

"So even starting with no details at all other than the first six digits -- which tell you the bank and card type and so are the same for every card from a single provider -- a hacker can obtain the three essential pieces of information to make an online purchase within as little as six seconds."

That's card number, expiration date, and CVV code.

From the paper:

Abstract: This article provides an extensive study of the current practice of online payment using credit and debit cards, and the intrinsic security challenges caused by the differences in how payment sites operate. We investigated the Alexa top-400 online merchants' payment sites, and realised that the current landscape facilitates a distributed guessing attack. This attack subverts the payment functionality from its intended purpose of validating card details, into helping the attackers to generate all security data fields required to make online transactions. We will show that this attack would not be practical if all payment sites performed the same security checks. As part of our responsible disclosure measure, we notified a selection of payment sites about our findings, and we report on their responses. We will discuss potential solutions to the problem and the practical difficulty to implement these, given the varying technical and business concerns of the involved parties.

BoingBoing post:

The researchers believe this method has already been used in the wild, as part of a spectacular hack against Tesco bank last month.

MasterCard is immune to this hack because they detect the guesses, even though they're distributed across multiple websites. Visa is not.

Posted on December 5, 2016 at 6:25 AM • 9 Comments

Comments

Stan SmithDecember 5, 2016 7:41 AM

Another attack vector may be automated scripting to 1800 authorization systems.

The GreatestDecember 5, 2016 10:49 AM

It will be a killer, and a chiller, and a thriller, when I guess the credit card security details in Manila.

M. WelinderDecember 5, 2016 1:52 PM

Sounds like visa will soon come under tremendous pressure from banks
to limit this.

Randy StegbauerDecember 5, 2016 2:44 PM

I'm slow. I don't understand how verifying more fields (PAN, Expiration, CVV2, and ZIP) would make the entire network less secure.

Do the vendors who authenticate with just PAN and Expiration have something to lose if they verify with more fields? My simple minded guess would be that it might cause fewer sales if a legitimate buyer fails on the first attempt and then leaves or doesn't understand what the CVV2 is.

However, shouldn't it *cost* them more to do less verification?

GaryDecember 5, 2016 3:30 PM

Randy -- merchants who validate more information will sometimes (usually) pay lower service fees to their processor due to the reduction in fraud. But more validation generally results in more rejected transactions. So each merchant has to figure out their own acceptable level of cost/risk.

WooDecember 7, 2016 9:58 AM

"starting with no details at all other than the first six digits" - but the rest of the paper all assumes you have a complete and valid card number at hand. That's a slight discrepancy.. unless you assume that you can reasonably guess an actually issued and sufficiently funded card from the issuer prefix and random values that result in a valid checksum.

TedDecember 9, 2016 7:57 PM

Here’s a talk with MasterCard’s Ajay Banga from 2014 presented by Stanford’s GSB. Mr. Banga is one of the 12 individuals who served on the President’s Commission on Enhancing Cybersecurity.

https://www.gsb.stanford.edu/insights/mastercard-ceo-ajay-banga-taking-risks-your-life-career

[9:51] And MasterCard had technology and data and even though I didn't do technology when I was a young kid, I did in school but not in college I just love the space. I think I'm half a geek somewhere deep inside where I enjoy the stuff and I enjoy data and I enjoy making connections…
[10:45] But if you've got 5,000, 2,000, 10,000, 15,000 people working for you, you can touch them, feel them, put your arms around them, they know who you are, they can understand you, you can make a difference. You can actually change things in that company.

After the first couple minutes, he talks about learning the concepts of high quality products and ethics, and about looking to work for companies where you can learn what you need in the early years of working life.

https://www.whitehouse.gov/the-press-office/2016/04/13/president-obama-announces-more-key-administration-posts

https://www.nist.gov/cybercommission

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient, an IBM Company.