There are well-specified rules for coming up with valid credit card account numbers, and at most, say, 60 valid expiration dates (12 months × 5 years into the future).
Once an attacker has a valid credit card number and expiration date, there are only 10⁴ = 10,000 four-digit security codes possible, which the attacker tries with parallel requests to hundreds of websites. Each website gives the attacker at least a few tries to enter valid credit card information.
Worst case, it takes only 10,000 parallel requests to guess the correct security code. Worst case.
You generally don't even need to get the right expiration date. As long as the date you supply is in the future it will usually work.
The security code also can sometimes be skipped. This varies from region to region, but in the US the credit card companies do not actually require a security code match for card not present transactions. The merchant can supply the code, and if so, the credit card processing system will report back on whether or not it matched, but it is up to the merchant to decide whether or not that should disallow completing the transaction.
Similar for customer address, by the way. The merchant can supply it and ask whether it matches, but whether or not a mismatch disallows the purchase is up to the merchant.
I think it also varies by processor, but I'm not sure on that one. One particular jerk merchant accepted my order for a few hundred dollars worth of car parts, then told me that he would only ship to my billing address. When I told him no and explained that my mail gets frequently stolen at that address, which is why I wanted my order shipped to the other address, he refused to cancel my order, and told me I'd need to call my bank to add the other address before he could ship my stuff.
At this point, he had not charged my card. I told him that if he did charge my card, I would file a chargeback. He charged it, I charged back, waited 2 months, and got a letter saying the chargeback was finalized and my refund was no longer "pending". Idiot cost himself probably 6% of the transaction both running it and paying for processing the refund, plus got a bad mark with his merchant account. He did all of this because he thought my transaction was fraud since the billing and shipping address didn't match (yet he refused to cancel it and charged it anyway).
I just checked. I have three AMEX cards (Platinum, Blue Cash Preferred, Green) in my wallet. All three have both four-digit numbers on the front as well as three-digit numbers on the back.
I don't recall ever being asked for the three-digit code on the back (like I am with most VISA/MasterCard credit cards). It's always the four-digit one on the front.
The Apple Store (as in, the actual brick and mortar establishment) started using the 3-digit code on the back of my American Express card at some point instead of the 4-digit one at the front (but they are so far the only company I have personally run into which does that).
It does - there is a 3 digit number on the back in the signature strip. The Amex website will ask you for it if you attempt to change your phone number, amongst other similar high-risk transactions.
I have been asked the 3 digit code when booking an airline ticket on a non-US site. During payment it passed through a amex safekey site which I think is kind of like 3d secure
there are only 10⁴ = 10,000 four-digit security codes possible
Yeah, that's not a big number, even manually, much less for a hacker.
I went to school for two months and the TV in my dorm room had been locked down to a few channels by some parental security crap, presumably by a previous occupant. With nothing better to do, I manually went through codes until I found the right one and unlocked it to open up more channels for myself.
It was only intimidating when I was entering random guesses at first. As soon as I decided to just methodically go through all possible combinations, it only took me something like two or three days of doing this when I wasn't in class and was watching TV anyway.
I am so glad I never tried to use BS like that with my own kids.
I am not a hacker, but other remarks here have cast light on how hackers do that. Those remarks fit with what I know about fraud from when I processed insurance claims for a living.
For any valid card number yes. I'd bet that almost all don't have three numbers all the same and that there are probably more rules/conventions that would reduce the search space.
> I'd bet that almost all don't have three numbers all the same and that there are probably more rules/conventions that would reduce the search space.
You're correct that almost all don't have three identical digits, but that's just because there's only 10 of them -
000, 111, 222, 333, 444, 555, 666, 777, 888, 999
10/1000 = 1%
I doubt they would make up rules for determining the cvv, as it would only improve security until bad actors could determine the rules - then it would hinder security as there would be less entropy in the selection space.
A coworker of mine thought the same. Parsed the string into an int - we saw a bunch of cards get declined by our gateway processing company. They definitely can have leading zeroes.
I'm sure it may seem so for someone who's really never dealt with fraud, but it's definitely not as easy as just signing up to amazon and making an order.
If you tried to use UK cards gained from doing this, I assure you, not a single one of your orders would ever ship.
You'd just be wasting your time getting all your drop addresses (or purse customer addresses) blacklisted.
Not really, purse.io does not facilitate fraud more than Amazon itself does. Purse.io just connects people who are willing to buy bitcoin using Amazon gift cards for a premium, and those that would like to purchase products on Amazon using bitcoin.
It's an out and out money laundering service. It exists for no other reason, there are no legitimate circumstances where someone would want or need to sell amazon gift cards at less than their face value. It is straight up money laundering and it's frankly incredible that it's lasted as long as it has.
> no legitimate circumstances where someone would want or need to sell amazon gift cards at less than their face value.
Absolute statements like this are so hard to back up.
For instance, if you live in Cuba, Iran, Syria, North Korea, or Syria, Amazon.com gift cards are worthless.
I know I received some AmericanEagle gift cards as a promotion recently, and unloaded them for less than face value just because I had absolutely no need/want to use them.
> there are no legitimate circumstances where someone would want or need to sell amazon gift cards at less than their face value
Many credit card rewards programs offer Amazon gift cards as a redemption option. The points:value ratio on these is generally significantly better than the ratio on cash rebates, even when you consider the hit taken on sites like purse.
e.g. 10,000 points might be redeemable for $100 in Amazon GC, but only $50 in cash, so even if you get the GC and sell them for $85, you still do better than if you had straight redeemed it for USD.
You can potentially issue an old-style mag-stripe credit card knock-off, and pay with it in an offline store. IDK if it's worth the effort: the card should look reasonable physically, too.
No, there's an analogue of the CVV2, the CVV1, which is only present on the magnetic stripe. The information you'd get from an online transaction is not enough to print a working magstripe.
Yep, ever have a merchant enter your CC number on the keypad IRL? That's what's happening. The fees for these types of transactions are typically higher as your processor is assuming more risk, so they prefer to only do them when they need to. See https://www.mastercard.us/content/dam/mccom/en-us/documents/... if you're really curious about how this stuff works in the MasterCard case. Visa is similar AFAIK.
So criminals can guess a valid CC/CVC/Zip in 6 seconds, and merchants that get nothing but green lights across the board from their credit card processor will be left holding the bag when the card holder disputes the charge.
Merchants doing everything they can need better protection from this crap.
I designed the fraud prevention for a major ecommerce site(PCI Level 1). We used to get hit with lots of card testing including bot nets. They are easily mitigated. First thing is detune your error messages. Combine all the errors into one generic message. This includes AVS, CVN, and Expiration. I've see so many sites return the raw message back from the processor.
We also actively black holed large blocks IP addresses including TOR exit nodes and open proxies. Before all the privacy people make comments. We're a store. If you show up wearing a ski mask we aren't going to sell to you.
Sometimes we go on the offense and detect the patterns/attributes for the botnets that allowed us distinguish them from real traffic. We didn't block them, we fed them bad data. That made them go away fast.
Most important take away: Mitigating fraud will lead to higher auth success rates as you build up the reputation on your MID(Merchant ID). Its not only important in preventing chargebacks but increasing revenue.
Its opposite in my experience. Detuning error messaging will increase abandonment as users wont know how to recover from errors (Eg invalid CVV) - thereby decreasing revenue. Its especially true where something like 3D secure is in use and failure messages varied.
Ive also never seen risk based authentication based on MID in place at issuers (Im in SEA it could be different in more developed markets). Rather they have blanket bans on MID or categories of MID with high fraud-to-sales ratios. Payments processors and acquirers have fraud detection systems, but they will score not actively decline.
So while someone abusing your service may land you in hot water, reducing their ability doesn't necessarily mean a higher authorization rate for regular transactions.
Regarding error messages: At a previous gig, we had to aggressively and repeatedly fight the business side who thought that vague credit card error messages were a large source of user confusion. Eventually, we won but it was certainly an eye-opening moment for the developers involved to even have to fight that battle.
I've had the same argument many times over error messages for login and forgot password flows. Being security conscious is a way of thinking that many people aren't really capable of and an even greater number have problem maintaining consistently. It's so ingrained in product managers to make their software as friendly as possible that they forget that sometimes their users don't have similarly noble intentions. This is also why social engineering is so successful. When it's your job to be helpful, it's very difficult to be strategically unhelpful when necessary.
Score your users based on attributes like whats in cart, IP reputation, browser/os, pages visited, source,3rd party fraud detecton providers etc. Score should reflect how likely the user is genuine or not. For well scoring users which should be 90% of your traffic, provide them with detailed messages.
I wish sites like newegg would treat customs with successful transactions as safe. I've had many times where they've outright canned an important order for really no reason. Trying to get them to accept it is a whole other hassle.
I have been. Despite it sometimes costing more I buy all my drives from other vendors. Mostly been amazon recently. They're cool with taking my huge orders.
There are tradeoffs, you have to balance security with usability. Generic payments failure messages are responsible for a lot of frustration in users, especially users who are paying online for the first time and have to go through complicated payments processes like 3D secure.
As a programmer, I get it, but as a user there's been a few times where I fat-fingered a number or an address and the payment failed - it was then a minor PITA to figure out exactly what I got wrong.
The merchant is not just left holding the bag. The merchant has to buy the bag...and it is not a cheap paper or plastic bad. It is a fancy, expensive, designer bag. When a charge is disputed, the merchant pays a fee of typically $15-30, regardless of who wins the dispute.
In other words, there are two possible outcomes to a dispute:
1. Merchant loses. Merchant refunds in full that amount of the charge plus $15-30 for the charge back processing fee.
2. Merchant wins. Merchants gets to keep the amount of the charge, but still must pay the $15-30 charge back processing fee.
From the merchant point of view, the credit card system is very annoying in that regard. If anything happens that requires that someone gets screwed, that someone will be the merchant.
The banks will not allow themselves to be screwed, because they run the system.
The credit card holder is a direct client of the banks, and the banks protect them to keep them happy.
The merchant account provider, which is where the credit card companies actually send the money for the merchant's sales, and is the entity that the credit card companies turn directly to in the case of chargebacks or fraud, protects itself by holding back part of the money it owes the merchant. The merchant account provider ends up holding a buffer of sometimes tens of thousands of dollars of the merchant's sales.
Worse, the merchant does not appear to be able to really know when payment from a credit card is actually final. According to nearly everything I can find on the net and in credit card company documentation, the limit on how old a charge can be charged back is 6 months or 1 year.
I know that is wrong because at a company whose payment handling software I maintain, we got a charge back on a transaction that was several months past a year old.
Another thing I saw that I would have thought impossible had I not actually saw it, was we had a customer who bought a subscription to a monthly service. The initial purchase went through fine (transaction comes back approved, and a day or two later shows up as settled and paid). The renewal next month went through, and so on, for the next six months or so.
Then we got a notice that the last several of these had not actually went through. The issuing bank had told the credit card processor that the transaction was approved, but we were told it was really declined, and no money was actually transferred.
> Worse, the merchant does not appear to be able to really know when payment from a credit card is actually final.
This is why I find it strange when people wring their hands over Bitcoin's 10 minute settlement window... Credit card transactions are regularly open for weeks if not months!
From the consumer perspective CC transactions are effectively instant, at least for the strip transaction. Even introducing the short delay that the chips involve has been very unpopular. (Why they went with chip+sig is clearly some form of non-security motivation.)
The solution to bitcoin, ironically, would be bitcoin+signature. The signature is forming a contract, a promise to pay. This is different from waiting for /an/ actual payment to clear.
From my limited use of Bitcoin, the merchants only required the transaction to be broadcast They didn't care if it had 0 or 1 or 100 confirmations. They only cared that it was broadcast. Which makes sense. Considering they all apparently only did 4 Bitcoin transactions a month if not less. (2 cafes and a pub)
This is completely different to how online stores have processed my Bitcoin. Usually waiting for 1-2 confirmations before shipping (Trezor is my example here)
But I can buy a coffee with my credit card without having to wait weeks or months to get it. This works because people have faith in the system, faith which in turn is built on identity information and legal systems. You could probably achieve the same thing on top of Bitcoin, but at that point why bother with Bitcoin (and the cost is nontrivial)?
Transaction processors also face fines if the dispute percentage is too high. They don't have forbidden business lists just because they don't like pornography or sex toys. They can also be defrauded by merchants too: Make a fake business, make some fake purchases to yourself and after you get your money, disappear. Then a financial institution is the one holding the bag.
That said, it's absolutely true that an online merchant needs protection from fraud, way past what anyone that isn't Amazon-sized can do on their own. There's third parties that do check prior to any processor. You can also rely on a processor that does more checking, or allows the merchant to made adjustments based on the level of risk they want.
> They don't have forbidden business lists just because they don't like pornography or sex toys.
Those are "high-risk" mainly because of "reputational risk", not because of chargebacks. Which I imagine is code for Visa or the banks thinking "If too many people with traditional morals get into political office, they'll start cracking down on us if we do business with the sex toy companies." https://en.wikipedia.org/wiki/Operation_Choke_Point
There's also some bad history with old porn sites, since they used 0-days to install dialers on people's computers to rack up tons of money when they used their dialup to connect to the internet. Hence the old "I think my computer has a virus", "Quit browsing those weird porn sites" retort you may have heard. They did other shady things which got Visa in a bit of trouble. It doesn't happen much anymore, but I suspect the organizational scars remain.
You've insinuated that pornography or sex toys are often "forbidden" because they have a high chargeback rate. But if you have 0 chargebacks after a few years, you still won't be able to negotiate a lower rate or to use a service like Paypal or Stripe. Because chargebacks aren't the reason.
Visa and MasterCard charge you $500/year each as an extra fee too, so I suspect the Stripes and Paypals of the world can't combine them into their aggregate account. A fee like that would seem to preclude even a specialized aggregate account, without a special agreement with Visa.
Also, if chargebacks were the issue, I would expect companies that only take debit cards to be in a different risk category than those that take credit cards. Debit cards have reduced fraud protection, so a Paypal or Stripe's underwriting should be more lenient for them. But I've never heard of Stripe letting you sell porn or of Visa waiving the fee if you only take debit cards. It could just be uncommon though.
Plus, I believe both Paypal and Stripe ban selling porn even using e-checks, which is more evidence against chargebacks being the issue. There shouldn't be any restrictions on the ACH system, and even if there usually were somebody could set up a state credit union in Oregon or similar to handle it.
> Those are "high-risk" mainly because of "reputational risk", not because of chargebacks.
This may be partially true, but I'd imagine they still see a higher rate of chargebacks. "What's this on the credit card bill, honey?" "Porn?! Someone must have hacked my intertubes!"
It does, but the only allowable reason is "not authorized". Of course, for this type of fraud, that's the reason that matters.
Thought it worth mentioning though, because in the CC world, a lot of the fraud is return fraud. Like "Item Not Received" or "Not as Described" being used when they aren't true.
I wonder how much of "Item Not Received" is due to poor transport security, like delivering the item to someone's 'property' but just leaving it outside, unattended and unsecured.
That's part of it. The chargeback system is a complete joke, however. I had one guy that I was very suspicious about, so I hired a PI to see if the item was visible in his small business, and take a picture.
The tracking number showed the item delivered to the person, signed for with an known employee's name. I submitted this, as well as a picture of the item in the guy's shop. I still lost the chargeback. Got my revenge in the end though...see below.
A tip for anyone that's has a particular chargeback where they know they were screwed. If the issuing bank has any presence in your state...sue the cardholder's bank (or perhaps Visa/MC/AMEX) in small claims. In my case, Chase settled for the amount I sued for, which I made sure was on the high side. They don't like to spend money on corporate lawyers going to small claims.
First off, what a jerk, glad you got your money back. Second though, too bad you can't sue for damages in time wasted stressing out about this and having to file a lawsuit + likely do some research. Hopefully it was at least a few grand to make it worth your time. Hopefully also you appealed the first chargeback decision, which I'm guessing took at least a month or two.
Some people just seemingly think of creative ways to screw other people for fun, or because they figure no one will stop them.
Well, in most small claims court cases they can't send a lawyer, and have to send an employee who is unfamiliar with the case, which for a company like Chase may mean flying in an employee and putting them up for a night or two.
Fun aside. In the UK the Bacs system (similar to ACH) has no time limit on chargebacks (called indemnity claims). So you could do an indemnity claim there 10 years after the debit.
Kogan charge your card a slightly lower random amount than the transaction total and ask you to verify the exact figure before they will fulfill the order. Simple and clever.
Merchant gets charge backs, and back when I used to run a small online business, these were $25 a pop. Any kind of "online protection tools" would reduce the fraud by a bit , but nothing eliminates it.
Shouldn't this be easy to detect, though? Every attempt to use a credit card number online involves a request to the bank providing that card to determine if it's valid, right? So the bank would see thousands of attempts across hundreds of websites for the same card number in a matter of seconds, which is clearly impossible for a human, and flag the card as "stolen".
Or maybe I'm just way too optimistic about how this all works.
Actually, it's not even close. 10,000 attempts to guess a 4-digit number are certain to succeed. 100 attempts to guess 100 4-digit numbers have a good chance of resulting in no hits. For each 4-digit number, you produce 100 different guesses (with no repeated guesses for that number, because that would be silly). There's a 100/10,000 chance of a hit, and 9,900/10,000 chance of a miss. The chance of missing on all 100 4-digit numbers is (9,900/10,000)^100 = 0.366 = 36.6%. That's substantial!
Guessing 100 numbers, there's a chance to produce 2 or more hits, of course.
The expected value of both strategies is to have 1 success, but they have different variance. The first strategy has variance of 0.99, and the second strategy has variance 0. The chance of n out of 100 hits with the first strategy is: binomial(100,n) x 0.01^n x 0.99^(100-n)
edit: asterisks as multiplication signs => italics
But that means you have pretty low conversion rate. You have 1000 numbers of stolen cards, and you only going to get 10 of them? It reduces profitability substantially. And even 100 attempts is enough to mark card as stolen if bank is watching it.
They don't need to steal a card at all to do this. They're just guessing random numbers — everything after the issuer/cardtype numbers (first 5 or 6). So there's nothing to convert, and they only try a particular card number a few times.
Sadly, the banks don't do much about it, because for US card-not-present transactions...they have no risk. Any fraud is paid for by the merchant seller.
It's too bad, because if there was an anti-fraud system that had access to ALL transactions + ALL data, it would obviously work better than any other solution.
Yep, it would cost them to implement and maintain, and they have no financial incentive to do so. It's not like they have a brand to ruin either; everyone already hates them, but Visa and MasterCard run the US market (and much of the global market), so they can do whatever they want to consumers without fear of backlash / loss of business.
That was one of the points in the article. Since the merchant implements the limit and not the bank itself, you work across N merchants and you get plenty of attempts.
And if the merchant is trying to be "consumer friendly" and accepts a relatively high number of failures before blocking the transaction, the allowed number of attempts is probably staggering.
The power of distributed attacks. Of course they can only guess a random correct credit card + exp + code not yours. Given the relative limited number of codes for each bank, I wonder what the odds are for them to wind up with yours.
It's like winning the lottery --- someone always wins, even if it's not you. If guessing is free and you get an effectively unlimited number of guesses in parallel, it's pretty obvious that you will win quite easily.
...for every valid/correct credit card? The answer is a ratio of 1:x_1, where x_1 is every correct cc. And each correct cc is a ratio to the total number of cc vulnerable to the system of attack, 1:x_2; and this is in turn a ratio of 1:x_3, for all the currently valid cc, etc.etc. Right? But what's more concerning is all of the successful fraudulant activity is adding to the loss those banks are adding to their books, which in turn will be passed on to customers as bank fees and other costs.
There is no loss to the banks, assuming the fraudulent purchases are "card not present". The loss goes to the selling merchant. Your point of it being collectively passed on to the consumer is still true, of course.
Acceptable storage is usually first 6 and last 4 [1]. I wonder if this would make it easier to go through some Luhn checked generated numbers to target an individual.
Securing the current protocol for credit card transactions is completely hopeless. It is inherently insecure because the "secret" information used to authorize a transaction is not bound to that transaction, and so it's reusable. Even if you were able to secure the system against brute-force attacks like this one, you can never secure against phishing. The only way to fix it is to change the protocol to one that relies on public-key cryptography and secure digital signatures.
EMV tokens and virtual card numbers attempt to mitigate against the re-use factor. 3D secure adds a layer of auth to the regular method (at some expense).
There is a large infrastructure (acceptance, processing, acquiring, clearing, issuing) running on card numbers so the solutions mentioned above all attempt to build on top of them as oppose to replace them with something better. As the logistics of doing so tend to be prohibitive.
I'm no means on expert on this, but having delt a little with online transactions from testing responses from a payment processor.
The things that needed to match also involved the customers street address, zip and name. If I recall these were scored and if the match wasn't good (zip was entered wrong) the transaction was rejected. Maybe different payment processors have different thresholds for rejecting a transaction?
For US based transactions, AVS failures (address, zip) don't typically fail the transactions.
Most often, the api has 3 possible return values "Success", "Success With Warnings" and "Failure".
The "Success with Warnings" will have some error codes for AVS failures (street address, zip). Usually the same for invalid CVV2. I've also noticed that cardholder name matching isn't universally supported...AMEX does it well, but VISA/MC is hit or miss.
Most merchants choose to allow for "Success with Warnings" and then manually check them.
It's hard to automate, because it's very typical for real customers to mistype billing addresses, CVV2, etc. One good example is small business owners. They, very often, use their business address as billing, even when the billing address is actually their home address.
In short, you can configure for hard failure on address mismatch or CVV2 mismatch, but you're throwing away a lot of legit transactions if you do so.
That's entirely up to the merchant, not the processor (or the gateway, either of the banks, or any of the other middlemen). From the link you gave "You will need to log into your payment gateway website and adjust these settings as you learn your customer profile and behavior." Most merchants want to sell things, and don't want to constantly field complaints from customers (or bad word of mouth from lost customers), so they set them to rather loose settings.
The fraud checks go through many middlemen each with their own systems, with their own bugs and limitations. Any programmer could guess a few. If the address is "apt 2, 300 main street" entered as "300 main st, apt 2" (or vice-versa), it can fail. If the zip code is 9-digits entered as 5 (or vice-versa), it could fail. Of course, the customer doesn't know exactly what pattern the system is looking for. If the punctuation is different, it might fail. If there are unexpected characters or encodings that any system or network in the chain can't handle properly, it might fail. If any of the systems is in a different country from any of the others, it might fail. In fact, AVS doesn't work in most countries (or at least didn't, last time I checked.) The internet brings international customers, but the payment systems aren't really internationalized.
So the question becomes, do we tighten this down to try to reduce fraud at the cost of losing 2/3rds of our regular repeat customers and limiting ourselves to only U.S. customers? Unless the cost of fraudulent transactions regularly exceeds 2/3rds of your revenue and you're intentionally a U.S.-only business, probably not. Companies would rather ignore AVS and expiration date failures than go out of business.
My memory is fuzzy, but I believe this depends on an issuers and acquirers. There are acquirers who do not check for anything but card number, expiration date and optionally CVC. And there are issuers who do not have AVS (address verification) support, which I think is almost all issuers outside the States.
Most modern payment gateways will enforce CVC check, and require the name to be present, though.
Believe that the address validation only checks the numbers present in the address, not the rest of the text, at least that was what I read in some gateway's documentation. Imagine the level of what they check may vary.
This is of course if the merchant/gateway even cares about that level...
A solution that some banks provide is to enable a credit card for only transactions using 3-D Secure [1], in which you are expected to enter a 2FA code sent to your phone by the bank during transaction to a webpage of the bank that gets opened.
Unfortunately, some (most) websites don't support 3-D Secure. I remember that almost all Turkish e-commerce sites I shopped supported it but almost none of the American sites supported it.
Does your bank also reject all non 3-D Secure transactions?
Unless this is the case, having 3-D Secure only benefits merchants as the liability will now be shifted from the merchant to the cardholder (e.g. the cardholder is now liable for fraud) while the (stolen) card can still be used for a non 3-D Secure payments.
The liability is with the merchant for non 3D secure payments, just as it's with the provider for old stripe-and-signature payments even after the switch to chip-and-pin.
Fortunately, merchants and banks have realized that requiring 3-D Secure results in an abandoned shopping card.
I rarely use my CC online. Asking me for my 3-D Secure password means asking me to log into my bank and use a physical second factor to set a new password.
Likewise, requiring 3-D Secure on my credit card makes me much more likely to pick a different payment method since I don't feel like doing the above. (Or rather, I might not even be carrying the phone/token needed for it.)
Seems like someone has figured this out. I haven't seen a 3-D Secure prompt in a while.
There's also no reason for me to like it: Without 3-D Secure, fraud is a minor hassle and I'll get my money back. With it, the bank may try to put the responsibility on me, even though I can't distinguish a real 3-D Secure page from a phishing page because they're all IFRAMEd per their official recommendations.
As a customer I hate these 2FA codes and online bank confirmations, common in the EU. I don't want to bring my bank passwords and whatnot with me if I want to make an online purchase with my CC!
As a customer they are also entirely to your disadvantage as in any 3dsecure transaction the customer is liable for unauthorized transactions as the assumption is they are the only ones with the ability to authorize. This makes disputing charges extremely difficult for the customer, and shifts liability from the bank and merchant to the customer end.
Some banks appear to have lighter-touch 3D Secure than others. I switched to my current (UK) bank when my previous bank, HSBC, introduced a mandatory keypad for online banking: no way did I want to carry that around everywhere I might want to check my balance or transfer money. The bank I now use doesn't require a keypad for personal banking, nor a password for most 3D Secure transactions.
There's just not much incentive to support it. You have to make it optional, otherwise your conversion rate drops like a rock. And, if you make it optional, only a very tiny amount of customers ever use it...and the ones that do are VERY unlikely to be fraudulent users. Thus, the shift in liability isn't really an incentive.
The only way it would work would be to make it 100% mandatory. The checkout path would be harder on customers, but they couldn't choose to go to a competitor's site that didn't require it.
3-D Secure doesn't always requests a 2FA code sent to your phone.
Most that I've used are fixed passwords (and they ask you for the character at certain positions) while others will ask you for personal information that is rather easy to obtain.
This is at least my experience. From the handful of cards I've used from different banks, only 1 used to send me a code via SMS.
In Turkey, it became a requirement from nearly all banks supporting online transactions. I couldn't find out though if it was forced by BDDK (Turkish authority of banking regulation and inspection) though.
This is most likely the merchant choose to enable 3-D Secure for large transactions so they're not liable for frauds.
3-D Secure flow is separate from the normal authorization flow and require the merchant (or payment gateway) to set it up. The merchant (or the gateway) is required to build or purchase an MPI from an approved vendors to make it work.
The article stated that Tesco weren't protecting against distributed card testing because they didn't track failures on the same card across different merchants. Thus I think it would be very plausible.
The people running the scam would choose a specific IIN/BIN known to suffer from this problem.
Unfortunately, at least in the US, cardholder name matching doesn't work for most transactions. Only AMEX supports it.
Edit: Offtopic rant, but as an online merchant this is the sort of thing that pisses me off about the CC situation. They don't support other obvious things either, like passing in the shipping address and ip address so they can be used for fraud detection. Yes, there are outboard services (MaxMind,etc) you can use, but they are working with a small subset of transactions, so their algorithms and blacklists are incomplete.
Matercard supposedly has a single back end but VISA does not, according to the article. Given the distributed nature of the attack I imagine only the card processors could detect it; if you pick sufficiently broad set of web site to test with the chances of them sharing a server that could detect something is probably low.
It says this: "Whereas MasterCard’s centralised network
detects the guessing attack after fewer than 10 attempts (even when those attempts were distributed across multiple websites), Visa’s payment ecosystem does not prevent the attack"
As another poster said, you don't run one card 1000 times. You run 100 cards 10 times and achieve almost the same probability of guessing one without burning the card.
On another note, I wish they'd get rid of the number + exp + cvv. Quit concatenating more codes and just go to an alpha numeric model. You could have fewer digits and a bigger probability space. Even when you remove certain letters that sound alike.
That frankly sounds like a strong security argument to use MasterCard over Visa. But more research on how MasterCard would handle a similar attack might be necessary.
This does not require hindsight - it is literally the first thing you would ask about in an audit of the system's security. The real issue is what it says about the competence of the people running these systems.
Source? Do you audit credit card security systems or are in a related industry?
I personally tend to air on the side of NOT assuming people I have never met working on a problem I have never had to try to solve (and therefor may not see all the complexity) are incompetent.
I find it way more likely they are competent it is just a problem that is significantly more complex when dealing with the kind of big-data volume they do than it would be on a smaller scale.
Actually, I have worked on the development of security software, but if you want a source, I suggest you start with the work of the researchers mentioned in the article.
Among the facts there, you can find that Mastercard is apparently capable of detecting these guessing attempts, so as we are on the subject of sources, what is your source for your suggestion that this is an insurmountable volume-related problem?
You have a point about not casually attributing incompetence, but this does seem to be a particularly facepalm-inducing issue. I am willing to be corrected.
> your source for your suggestion that this is an insurmountable volume-related problem
I wasn't. But a problem not being insurmountable does not make you incompetent for not solving it (yet). Curing cancer is not insurmountable yet we don't call scientist incompetent for not having it done yet (at least I don't).
And before you say it. No, I am not saying this is as difficult as curing cancer.
I don't know enough about the issue to correct you or not. I just know a lot of great software engineers who have poured their sweat and blood into systems only to be called incompetent.
I've also seen open source developers develop brilliant pieces of software and then get called incompetent for a single bug. Because the bug was "obvious" (in hindsight)
That kind of attitude keeps people from taking risks. I personally think we need to encourage people to go into the tough problems and a lot of people won't if they risk being ridiculed for not solving them.
The situation is not remotely like the scenario you are concerned about. We (the e-commerce industry collectively) have a history of making many of the same basic security mistakes repeatedly, even though both the mistakes and the ways to avoid them are well-documented (SQL injection is a classic example, as is the use of easily-guessable secrets.) In my opinion (the source of which is me) the industry should be held accountable for its complacency and, yes, lapses in competence. Of course, being criticized by me in an HN comment is hardly being held accountable.
That's why you should enable two factor authentication on your credit card: online transactions would require confirmation with single-use password you receive by SMS.
I don't know if you're talking about the 3-D Secure / Verified by Visa system, but the major flaw of this technology is that the merchant is the only one responsible for putting it up or not.
I used to work in e-commerce and my company simply disabled the SMS protection because it would harm sales and the platform would sometimes completely crash.
On the other hand there is no way (that I know of) that I, as a customer, could prevent my card being used in non secured websites. So this system makes legitimate purchases harder and doesn't prevent fraud.
We need a different technology than credit card for online payments, they are not secured enough and any layer of security that we add around them won't work.
What cards allow this? I would do it in a second if that was a thing I could actually have. Not 100% foolproof but I'd bet it would stop almost all fraud.
Not aware of any cards specifically (outside of European chip-and-pin, but I don't think those usually work online), but this is the big argument for things like android/apple/firebomb pay.
Make a purchase, then sign off on your phone (or fingerprint reader on your laptop).
It obviously won't resolve the issue posed in the article, but it is definitely a step in the right direction and many of the major CC companies are integrating more and more. In five or six years I can easily see Chase and the like giving an option to only let the physical card be used in chip-and-pin mode and to require the use of an approved service for any contactless/online orders.
Obviously the approved services thing is a concern, but not a huge one.
These attackers are probably brilliant enough to make their mark in the honest tech business world. I suppose they are driven by the challenge of the crime.
If you total the credit card numbers for any particular card the answer would be the same. For example: totaling the visa credit card number might be 32. The hackers would have to guess the 3 set of numbers if they get the fourth set.
So my guess is they would try out different combination with the available expiry date/cvv number
It's pretty unfortunate that there is absolutely no federated, popular, and secure payment system in the US due to consumers and merchants simply sticking with older systems simply because "it's what we've always done."
There are many parties that would gain from a better payments system.
However the logistics of improving it are significant due to the number of highly regulated and kinda-fat and kinda-happy entities running the infrastructure.
Interestingly what has happened in India and China (success of non-bank payment wallets VS cards) is injecting a lot of the traditional players with a sense of urgency. Before this it would have taken a states intervention (Eg MEPS in Sing/MY) to improve acceptance through the launch of a new payments system.
Once an attacker has a valid credit card number and expiration date, there are only 10⁴ = 10,000 four-digit security codes possible, which the attacker tries with parallel requests to hundreds of websites. Each website gives the attacker at least a few tries to enter valid credit card information.
Worst case, it takes only 10,000 parallel requests to guess the correct security code. Worst case.
I don't know whether to cringe or laugh at this.