If the credit card was a person, she would have retired by now. Usually, the birth of this industry is associated with the distribution of cards in Fresno in 1958. Maps have become a miracle of commerce and have become an integral part of the global economic infrastructure, but their operation is still driven by decisions made in the 1960s and 1970s. More than half a century has passed, and some of these solutions are far from optimal.
In development, this would be called a "legacy system". Is it important? Definitely. Is it difficult to change it? Very. Not exactly what we would create today? Definitely.
Many developers of the original architecture have retired, very few really understand how it works, responsibility for the system is distributed over many places, only individual actors can make changes, and too many other systems in other organizations depend on the stability of bug reproduction, so rapid development of all this is unlikely.
Testing maps: a large-scale attack
Each system starts its life by planning the main scenarios of its use and the supported variants of these scenarios. More than fifty years ago, the main scenario for using a credit card was something like this: "A business employee, while in another city, wants to reliably confirm to a restaurant that he will pay for dinner, even if he has never been to it before and will never be again, even if there is no local branch of his bank in the city, even if he and the waiter are completely different people and in general they have no reason to trust each other."The ecosystem has invested billions of dollars in both development and financial effort (but with only a small amount of marketing) to convey to society that this very human problem can be solved with a small plastic rectangle. Forget about the person in front of you and focus on the plastic rectangle. If the customer has a suitable rectangle, then dinner will be paid for.
But today, there are many more scenarios for using credit cards. Most transactions are so-called "cardless transactions", which were previously a side type of transactions performed by phone or mail (paper!). Now the Internet dominates this area. Credit card makers failed to anticipate the advent of the Internet. And, therefore, their infrastructure needs to adapt to the opportunities and challenges caused by the existence of the Internet, and also suffers from the general difficulties of changing legacy systems.
For example, take credit card fraud - "carding".
Before using a stolen (or purchased: there is a whole ecosystem of companies with headhunters and specialized departments) card, fraudsters need to check whether it is valid. Stolen cards are quickly blocked by banks due to complaints from cardholders or fraud detection by the banks themselves. Every time a cashier (someone who has been assigned to directly receive valuables acquired through fraud) rolls a card, the risk for him increases - he does not want to risk the possibility of successful use of the stolen card. Everything should work immediately and without problems.
Therefore, before attempting to withdraw funds, the cards are tested. To do this, they usually find an online organization with relatively weak fraud control and perform a small transaction that should look everyday and inconspicuous. Scammers perform testing with thousands or hundreds of thousands of cards, trying to sift through the list (and sometimes even random card numbers!) and find the currently active maps.
Most often, charities are chosen to test their cards. This is partly because most of these organizations do not have strong defenses against fraud; who would try to fraudulently take money from a charity by making a donation to it?
Contributions to charity look plausible to banks, even if they occur completely suddenly. The cardholder read his daughter a book about whales, and then decided to make the first contribution to the nature protection fund? Extremely logical! This happens much more often than the first purchase BY an ossified cardholder.
Software development companies are also testing maps. I once spent weeks defending myself from a gang of criminals who made purchases of my software for $29.95 to extract money from the accounts of people I didn't know existed. It was extremely annoying. As an entrepreneur, there was practically nothing I could do.
I ended up spending dozens of hours writing code to outsmart the Evil inc. code that was written to use me for illegal purposes. Most businesses on the Internet don't have a low-paid Japanese white-collar employee, a computer security fan with access to a tech support mailbox and accounting documents, ready to take action.
However, let's return to charity.
The charity contribution is not important for the fraudster, they just need to see the "Thank you for your help" screen, which will confirm that everything went well. After a few days or weeks, when the fraud is noticed, the donation will be withdrawn from the charity, and the charity itself will most likely have to pay a fine. By that time, the fraudster will already be far away, calculating his profit.
Now let's go back to how the industry dealt with the trust issue: theft is not a new concept for a person! If you give people important pieces of plastic, for example, thieves may take the rectangles or try to fake them; both will become a serious threat to the economic system of plastic rectangles. So the architects of this system came up with countermeasures.
For example, credit card terminals have long been issuing obscure error codes like "04: Pick Up Card" and "07: Pick Up Card, Special Condition"to cashiers. The company should train cashiers to respond to them: both of these errors mean that the credit card system wants you to physically withdraw the card and return it to the bank, which has printed your address on the back of the card for this purpose.
The first error is intended for the case of a simple expiration of the card's service life. The second one is formulated evasively, so that scammers watching the terminal do not understand that the bank knows about the fraud that is taking place. This may give the cashier time to call the police, for example.
Please note that this structure places the burden of fraud detection on the bank. In the original threat model, this made sense: the bank had customer connections, it had data, and an expensive team of professionals. A diner far from home didn't have any of this. Obviously, the bank doesn't need to contact it either.
So can a charity say, "We think we've been victimized by card testing. Ten thousand people, none of whom we previously knew, used their maps on our website. Recently, we have not had any marketing campaigns that could have caused this. We did not send donation offers to those who had previously made contributions. Our site didn't get viral on Twitter thanks to our good work. The situation is extremely strange, and we hope that someone will address it." Alas, reader, she does not have such an opportunity.
Why did our industry create such a system? Because the developers could not imagine rolling ten thousand cards in an hour, because the one who would do this, the hand would fall off from the load. Therefore, this lack of imagination (quite logical and innocent!) decades later, it echoes in the present.
But that doesn't mean the problem is hopeless. Recently, companies have been working very hard to combat map testing, because due to the pandemic, it has become incredibly actively used. Why? This was probably partly due to the fact that real-life components could no longer be used in professional fraud operations, and partly due to the explosive development of electronic sales.
An increase in sales volumes also increases the number of fraud cases, while maintaining their basic frequency, and provides a disguise for brazen and large-scale opportunistic attacks on infrastructure.
It is very important to be able to detect that a particular organization has been attacked. Because these attacks are scripted, they often target a single organization or several organizations that use a predictable software topology.
Carding engineers are like any other engineers: there are people who tend to write simple scripts with hard-coded parameters, and people who strive to write complete generalized frameworks for exploiting the entire global economy. The first group ends up doing much more damage, because the second group doesn't release much software that can be used.
In principle, you can wait until the charity notices that it is under attack, and contact... someone who will contact specialists. In practice, from the point of view of specialists (not those who work for a charity, but those who see that this organization is fighting fraudulent transactions and take its side), it is more efficient to do all this work for a charity.
To identify organizations affected by map testing, my company uses a combination of machine learning algorithms, congitive and behavioral research, and the involvement of fraud analysts. Thanks to this, we can manually or automatically implement counter-measures in almost real time.
One counter — measure is to add a small amount of interference. The attack has an economic model: it is justified due to the fact that the costs (machine time on compromised machines that they rent from other criminal entrepreneurs, the attention of operators, and so on) for checking the map, it tends to zero. If you make them slightly less than non-zero, then the economic logic of the attack will be violated.
In the usual case, it is better to get rid of small interruptions in the shopping process! A whole industry of consultants has been created around this principle. Once upon a time, B2B SaaS companies paid me $30,000 a week to, among other things, perform A/B testing of their payment flows to reduce interference by a few percent, for example, to remove form fields that don't make much sense. An increase of 1% in the income of a large company very quickly justifies spending $30 thousand for a week of work as a consultant.
But if you know that someone is being attacked by map testers at this very moment, then adding a small amount of interference is useful. In addition to helping the public, it also quickly stops the attack.
This directly means that the victim organization will not receive a phantom profit, which will be quickly withdrawn from it, and then large monetary fines will be imposed. How does the credit card industry calculate penalties in this case? Using another legacy solution.
Obviously, anyone can be swindled once or twice, and in this case the fine will only be a minor expense for doing business, but if you have been swindled ten thousand times, then you should respond quickly under the threat of additional fines and penalties from the regulator. This logic made a lot of sense... in the 1970s. Therefore, the fine was chosen in such a way as to demotivate a business of questionable moral character from renting out its credit card terminals to criminals.
Credit card networks had to anticipate businesses that would take advantage of the public's trust, because these networks operate on the scale of the entire economy, and the entire economy includes some businesses that will abuse the public's trust.
The indirect effects of anti-testing are larger and are not limited to the victim organizations. The card testing attack is a tool for more widespread abuse of the financial system. By blocking card testing, we reduce the likelihood of subsequent fraud, in which the fraudster receives valuables. This changes the economic calculations, thanks to which there is a full cycle of fraud.
Hackers do not hack, scammers do not engage in scamming, and carders do not forge cards if cashiers ultimately do not have the ability to turn these intermediate funds into money.
How can I reduce the likelihood of success in fighting fraud? You can guess that rolling dirty cards is "loud" and can attract attention; this is why it is performed in charitable organizations, which are less likely to notice it and be able to do something about it, compared, for example, with a large retail chain that sells Playstation 5 in whole pallets and has a highly professional anti-corruption department. fraud.
Eliminating the possibility for fraudsters to conduct low-cost intelligence before purchasing free and easily resold goods significantly increases the risk of obtaining such equipment.
Someone will have to touch this Playstation 5 in the real physical world, and any hand that picks up a Playstation 5 can just as easily be handcuffed. Rolling in a retail store twelve cards, the delivery address of which is tied to a place nearby, gives experts to understand that this may not just be an innocent user who wants to surprise their children with a Spider Man game for Christmas.
And so the actions taken by companies like mine to directly protect their customers (the same charities) also protect companies that are not related to them in any way, which can use a completely different service for processing credit cards. That's how society works - we're all in the same boat.
Card accepting companies are ultimately responsible for credit card losses related to fraud. This is in line with laws, commercial agreements, and established practices. But it should be understood that a customer whose card has been swindled, even if they are compensated for all their losses by a complex chain of transactions, will still feel like a victim. They'll wonder if they've done something wrong (often they haven't).
He will spend several hours communicating with his bank and probably the authorities before he fixes all the consequences. By preventing criminals from turning citizens into victims, even if in financial terms it amounts to zero monetary losses, you are actually helping everyone.
Going beyond plastic for auth/auth
Credit cards initially combined the properties of possession, authentication, and authorization. You probably understand what" possession " means. Authentication is the confirmation that someone is who they say they are. Authorization is a confirmation that this person has the legal / moral right to perform the transaction, and that they actually intend to perform this transaction. We usually call this auth / auth, because people working in the credit card industry rarely have the opportunity to use cool words.For decades, the industry has had one solution - not optimal, but sufficient to provide worldwide reach and convenience. What is the solution? See this plastic rectangle? In the first approximation, you are the one whose name is written on this rectangle, and you are allowed to spend all the money that the bank indicated on the rectangle thinks you can spend. You have both authentication and authorization capabilities. Everything is very simple.
This incorrect model allowed us to build one of the most important financial infrastructure networks in the world. It was extremely useful...And then the Internet came along.
Before the ubiquity of high-quality phone cameras, it was extremely difficult to prove the ownership of a plastic rectangle over the Internet, but we still wanted to give people the opportunity to buy in it. So instead of relying on possession, we have relied on knowledge.
The user needed to know a very tiny piece of information about the cardholder and the relationship with the bank to show the intended authentication and authorization. Most of this information was physically printed on a plastic rectangle.
Knowledge is easy to copy, much easier than a plastic rectangle (which, unfortunately, criminals with a lot of resources can also copy!). Computers are based on the principle of permanent storage of knowledge and copy it very efficiently.
So the industry has come up with a rule: yes, some pieces of information can be copied, and everyone knows that this is necessary. But there is one particular piece of information, the security code on the back of the card, that you don't need to remember. If you don't know it, no one can copy it.
Asking every programmer on every computer system in the world not to write down a three-or four-digit number anywhere was, of course, futile. And the industry, in fact, often suffers losses on this, despite decades of application, for example, of PCI-DSS requirements. However, the optimal amount of fraud is not zero.
A lot of people here can step in and say, what's the big deal, you're smart people. You can ask for information that isn't printed on that damn plastic, right?!
Sure enough, the industry thought of this obvious solution. But it turned out that due to legacy issues, this solution is extremely difficult to use on a large scale, because these plastic rectangles are issued by tens of thousands of banks and handed over to millions of customers for decades. And it will be very bad if they suddenly stop working, and banks have huge amounts of interesting information about many customers, but very little consistent information about each customer.
Therefore, there were security measures like the Address Verification System (AVS). AVS was created due to regulatory requirements that require banks to "know your customer" (KYC), and KYC programs almost always require a physical address. The client's address was not indicated on the plastic rectangle and was a secret known to the bank and the client, but not to the fraudster.
Why didn't AVS solve the problem of credit card fraud? There are many reasons for this. One of them is that addresses turn out to be a bad secret, because the purpose of an address is to communicate it to a lot of people. We knew it, but we still used them!
In a world where finding someone's address requires independent investigation or the help of law enforcement, the need for scammers to identify each individual address was a good constraint on the frequency of fraud.
In an increasingly networked world, many people's addresses can be found with a single query in a perfectly legitimate and publicly accessible database. Many privacy advocates loudly blame the tech industry for this. Quite a few of them remember that we used to print quite large lists of addresses and phone numbers in a very large book, sometimes on yellow paper, and then distribute it, free of charge, so that it could be used by all citizens. These books are older than computers, not to mention the Internet.
In fact, sometimes databases do a better job of remembering addresses than the people they store information about. Any development team that has ever tried to compare addresses entered by people will be happy to tell you about it in great detail. Be prepared to spice up the conversation with a lot of alcohol, because you won't want to remember this damned knowledge in the morning.
So AVS is actually usually only used to reject transactions when the index doesn't match. This is one of the reasons why many of the sites you use limit themselves to just querying the index, as this is the only part that contributes to the balance between fraud and legitimate commerce.
Therefore, the industry is trying by hook or crook to move from authorization and authentication using what you know to what you have. And it's harder to copy or steal than plastic rectangles.
So-called two-factor authentication, in which the first factor is the information you know (credit card number and similar data), and the second can be what you have (for example, a cell phone known to your financial organization), has been actively discussed for almost two decades. In fact, it is legally binding in Europe, where it is called Strong Customer Authentication (SCA).
The rest of the world also has cell phones and banking apps. Why doesn't every business in the world require something like this for transactions? Because it makes a choice. This will create winners and losers, and the composition of these groups is quite difficult to predict.
In particular, initially credit cards for businesses were advertised as follows: they exist to give you more customers, so that they come back more often and you can sell them more products at a time. They are not only a payment tool; accepting credit cards is also a marketing decision.
An acceptable level of fraud or an acceptable level of inconvenience for law-abiding customers to prevent fraud is also partly a marketing decision. Some countries may conclude that this should not be a private decision and use the political process to regulate certain actions. Others do not take such steps.
Therefore, businesses in most of the world are facing the reality that many well-meaning customers will not be able to use 2FA because their financial institution does not support it, or because they have lost their 2FA token, or because they recently changed their cell phone number, or because their financial institution does not have their exact number stored. Alex Stamos, who once implemented this system for Facebook, correctly noted that managing the 2FA lifecycle is an incredibly difficult task worldwide.
Problems with 2FA are especially acute for customers who are close to the socio-economic marginal part of society! I sometimes wish that state regulators would talk to immigrants about the difficulties they face in the banking system, before, for example, requiring banks to work only with customers who have a phone number in the country.
In other words, there are difficulties that limit the ability of individual actors to innovate. But this does not mean that innovation is impossible!
For example, you can offer businesses a "carrot" that combines stronger auth/auth protection and built-in sales growth. There are many very interesting projects that implement this approach. For example, Apple Pay and Google Pay use a lot of different mechanics that make transactions much easier than having to enter numbers for the five hundredth time. This makes the business quite a lot of money.
This also has a well-planned side effect: binding secrets to a secure (in the case of Apple) or at least a hardware device with some degree of protection, which is harder to lose or forget than the previous 2FA dongles. Across the economy, this is still a problem, but to a lesser extent.
Actions at the appropriate level
Society has many different models for changing multi-layered networks with decentralized points of control. The most obvious models are government oversight and law-making.Various widely distributed actors, such as OSS projects, hardware manufacturers, or credit card processing companies, can also improve functionality without making disruptive changes. Sometimes they can even make these improvements so appealing that a spoonful of sugar will not just sweeten the bitter medicine, but also become a medicine in itself. A fascinating and infinitely interesting topic that I will definitely return to.
Original author: Patrick McKenzie
