Is debit (credit) card payment inherently broken from security point of view?

Question

TL;DR

I've been a user of debit cards for many years, and don't know much about the security issues. However, just thinking logically, I find the practice of paying by providing card data (i.e. card number, validity date, CVV code, cardholder name) inherently broken from a security point of view. I want to understand if my reasoning is right, and if so, why the system was designed like this. Or, if I'm wrong, what is the problem with my reasoning.

Background

In some online services/offline businesses, it is possible to pay by providing debit (credit) card data directly to the vendor (card number, validity date, CVV code, cardholder name). (And I think also off-line, by writing it on a paper, or by dictating it via phone.) Then, the vendor will charge the account using this data. (I imagine, that basically, he passes this data, together with the sum to be charged, to a card company, like Visa or Master, which check that they are valid and then instructs the bank about the amount to charge.)

I see (at least) two problems with this process:

• Nothing guarantees me, that the vendor will really charge the agreed sum and not more.
• Nothing guarantees me, that the vendor (who now knows the necessary data), won't charge my card again.
• (Let's forget for now about the issues like leaking card data, etc.)

If I want to compare it to a cash payment, the process seems to me like this:

1. I give my whole wallet to the vendor.

2. I go out of the room.

3. The vendor takes out from my wallet what he thinks is right.

4. I go back, get my wallet back, and only count the remaining money once I'm at home, not in front of the vendor. (If there was an issue, I can go back to complain later, but meanwhile, the vendor already has my money.)

5. From now on, the vendor has unlimited access to my wallet, and he can withdraw money whenever he feels like it.

Possible solution

What I would see as a secure enough solution: whenever someone tries to charge my card, I get a one time token sent to me (e.g. via SMS). In order for the transaction to be successful, I have to provide this token too. This solution seems so simple, and yet it could prevent (or at least make harder) most of the card frauds. The process would look like this: I get an SMS with a token. Am I paying for the service written in the SMS? Yes --> I give the token to my bank, to confirm the transaction. No --> I report the fraud attempt to the bank.

Remarks

• I know there is the possibility of a chargeback if the withdrawal was fraudulent. But why not prevent the possibility of fraud altogether as written above?
• Also, I know you can set limits for the transactions, still it does not eliminate the risk to lose at least some money.
• I'm also aware, you can have e.g. virtual cards for paying on the web. You can keep the corresponding account always empty, and only put money on it when you want to buy something with that card. There is still a very small chance, though, that someone will steal your money in the small time window that you've put it on your card but not yet spent it. (And in all cases, this is rather a workaround, not a fix for the root issue.)
• Putting additional security codes (e.g. CVV) on the card does not help much in this aspect (the vendor will get it, and can reuse it if he wishes).
• This question, although related, is not a duplicate in my opinion. The reason is, that the question suggests another solution (middle-man), and as far as I understand the answer, it boils down to rules/laws stating that vendors should not store credit card data. (But my problem is: why does the vendor have to receive data that he can reuse at any time if he wishes?)
• Also from the above Q&A, I read that there are laws which prohibit that the vendor stores (and reuses) card data. But this seems very weak. This would be like saying that there are laws that prohibit that the vendor takes more money from my wallet than he is due, while I'm not watching...
• There are some (in my opinion really dubious/unethical) practices from some hotels/car rentals etc. of pre-authorizing the agreed price and then, in the end, charging once again the price. (The pre-authorized transaction will be cleared eventually, but meanwhile, the user of the card does not have access to his money maybe for weeks.) This could also be easily prevented, by my one-time token suggestion (I would simply decline the second transaction).

Questions

(The more of these you can address explicitly in your answer, the better.)

• Is my understanding correct, that security of this payment method is broken? And is it broken in the way I think it is broken?

• If yes, then what was the reasoning for designing cards in this way?

• If not, then where is my reasoning wrong? (In particular, what is the difference between paying with my card by giving out all its data (cardholder name, card number, validity date, CVV), and giving my wallet to someone, so that he can take out the money himself, while I'm not watching? The only difference I can think of, is that the transaction with the card is at least logged somewhere.)

• Is there a well-known name for the issue I'm asking? (Of course, I tried to use Google before coming here, to search about credit card security, but I only got very particular results like issues with the security of the chip, and none of them addresses this issue within the model.)

• Why don't banks use the (seemingly trivial) method of the one-time token generated for the bank I proposed above? This works so well for money transfers (at least in my bank, I always get a unique number via SMS with which I have to confirm transfers). And why doesn't the answer to this question also apply to money transfers then? (In other words, why do then banks use one time tokens for money transfers? Why don't they just let any money transfer transaction succeed by default, with the possibility of claiming the money back, if the transaction turns out to be fraudulent?)

Answer 1

No full answer, just a few thoughts to consider:

1. Credit cards initially had to work in a fully offline environment (meaning that neither did the buyer have a cell phone available to receive a one-time token, nor did the merchant have a data line to the credit card company).

2. Credit cards are successful because they are easy to use and the owner doesn't have to carry the risk of fraud. Most attempts to make fraud more difficult, including yours, make them more difficult to use. It's hard to explain to your customers why they suddenly have to jump through all these hoops without any visible benefits.

3. While credit card fraud is obviously a big problem, it doesn't outweight the profits the credit card companies make, despite all their moaning about how much money is lost to fraud. So it's a question of optimization: How much more complicated can we make the payment process without losing so many clients that we're better off taking the loss of profits caused by fraud? Especially since the card holders seem to be willing to pay the current card fees, and while clients don't take a risk, merchants do - so often it's not even the credit card company that loses money when a fraud occurs, but the merchant. And since the merchant often has no choice but to offer payment by credit card, and fraud will be distributed among all merchants, it's probably not like the credit card company will lose too many merchant customers due to fraud even if it does nothing to improve the situation for merchants.

4. Card companies are working on solutions to make fraud more difficult. See for example this question MasterCard wants to replace passwords with selfies; how does this improve security? and my answer to it.

5. They might shy away from your SMS solution because first of all they'd need to send about 1700 SMS per second (this is roughly the number of transactions VISA claims it's doing), which if it costs them a penny per SMS would cost (just VISA) about half a billion dollars each year. I think that's substantially less than what they "lose" through fraud, but it's not exactly cheap, either. Second, it won't always work because not everyone has a phone, not everyone can use his/her phone if he/she's abroad, etc. So what happens if you want to pay, you have SMS verification enabled and your phone has run out of battery? Ooops. No joy. So they risk having lots and lots of angry clients, which isn't good.

Answer 2

It is true that given a third party becoming privy to all of the following:

• your name
• the card’s full number
• the CVV code

They can initiate a charge to your card.

Now your proposed solution is actually called 3d-secure (congratulations). It’s a form of 2FA, and the owner of the card will have to confirm attempts to charge the related card by sms, or online on their phone, etc... This is known commercially under various names, like « Verified by Visa » or simply 3D-secure.

It’s an imperfect solution which places a significant part of the burden on individual merchants, so only those who pay for the functionality will trigger the confirmation when charging your card. Please note that this is designed for, and marketed to protect the merchant as well against less scrupulous « customers » declaring a fraudulent charge after having enjoyed the service or received the goods.

Granted the scheme would benefit from being more pervasive and not require a party of the transaction to actively enroll (i.e. be on by default). This too has its own problems, like what if you can’t confirm on the spot (battery died, no cellphone reception...)? The merchant can’t just let you walk away with the risk you’d cancel the charge, so the transaction falls apart.

So at the end of the day, given imperfect technological solutions, it comes down to a matter of trust. Do you trust whoever you are transacting with to behave honestly and responsibly? Do they trust you to not charge back when you get home? Who gets to be harmed in the event of fraud? The card system is designed to be resilient against this, and despite money being lost to fraud, this is still less than the overall profit made, so banks accept to bear the burden of fraud to enable regular people to use debit/credit cards and get their money back in the case of fraud. This too you will trust.

In conclusion, cards are made to be convenient to use rather than fully secure. It’s a compromise to be made in order to adhere to the overall system. What you lack in security you make up with trust, and some necessary backup from your card’s issuer.

Now addressing a few thoughts on some of your points:

• the CVV code is designed to protect against someone photographing or shoulder-surfing your card and getting the front-facing name and numbers. It’s not designed to protect against anyone privy to it.

• Blocking funds on your account is not « double charging ». It’s a precaution merchants take to ensure you have enough money to pay for the goods or services. The money does not leave the account, and does not go into theirs. It’s a normal procedure, but it could indeed be quicker to release. Denying the actual charge (which you called « second charge ») would be fraud in itself.

• Why aren’t banks proactive in implementing a pervasive 2FA system? Money (expensive), difficulty in marketing it, resistance to change from their customers, possible loss of business due to failed transactions, overall lack of incentive (high profits)

Answer 3

While at an abstract level, the design has some merits, basing it on SMS rather undermines the objective. SMS is an asynchronous messaging protocol with best-effort delivery and (in Europe at least) is ridiculously expensive (in terms of bandwidth, providers charge approximately 10000 times more) compared with IP over GPRS/LTE. i.e. its expensive and does not fit the requirement.

Your next problem is that to get a working payment standard, everyone participating must agree to it at the same time (or near enough). The banks have already tried to solve problem with chip & pin - a design with some head-smacking technical flaws baked in - which has taken decades to roll out. Despite those flaws it still addresses the key problem as your design. Yet despite the fact that chip&pin is considered to be well embedded in Europe and nearly there in the US, the payment processing industry still honours CNP transactions (CNP = customer not present = giving your details over the phone). i.e. there are still too many use-cases it doesn't solve.

Answer 4

Thanks to all, who took the time to answer. You gave me very useful insights and new knowledge. Based on your input, I'll try to answer my questions myself.

I would be glad if someone could comment on it, to see if I misunderstood something.

Is my understanding correct, that security of this payment method is broken? And is it broken in the way I think it is broken?

Yes, and no :) Yes, it is true that anyone who has debit (credit) card data can initiate a transaction. However, the analogy is not 100% correct.

If yes, then what was the reasoning for designing cards in this way?

Three reasons:

• Historical: when they first introduced credit cards, it would have been more difficult to build such a mechanism, because mobile phones were not so widespread (if available at all?) at that time.

• Comfort for the user: it would be cumbersome for many using cards to suddenly have to perform one more step.

• Cost: for banks / card companies it is cheaper to pay for money lost due to fraud than to pay for introduce this whole new mechanism. (Well, I guess from the three reasons this is the real one ;) ).

If not, then where is my reasoning wrong? (In particular, what is the difference between paying with my card by giving out all its data (cardholder name, card number, validity date, CVV), and giving my wallet to someone, so that he can take out the money himself, while I'm not watching? The only difference I can think of, is that the transaction with the card is at least logged somewhere.)

Difference is the following:

• All transactions are logged, by an independent third party, so it is easy to at least prove the act of spending a given amount of money.

• In case there is a fraud the bank (or the card company) carries the loss not the user of the card (at least in theory -- my experience is different (*)).

Is there a well-known name for the issue I'm asking? (Of course, I tried to use Google before coming here, to search about credit card security, but I only got very particular results like issues with the security of the chip, and none of them addresses this issue within the model.)

Still open, I can't believe noone before me ever wandered about this issue...

Why don't banks use the (seemingly trivial) method of the one-time token generated for the bank I proposed above? This works so well for money transfers (at least in my bank, I always get a unique number via SMS with which I have to confirm transfers). And why doesn't the answer to this question also apply to money transfers then? (In other words, why do then banks use one time tokens for money transfers? Why don't they just let any money transfer transaction succeed by default, with the possibility of claiming the money back, if the transaction turns out to be fraudulent?)

See also above. In short: it costs more than it would bring for the banks/credit card companies. (This cost also includes satisfaction of majority of users, who care more about comfort than security...)

What nobody addressed, but I can kind of infer the answer is: why do we have this two step authentication for money transfers then? And I guess, the answer is "because it is cheaper to prevent fraudolent transfers, than to carry the risks" Btw., I'm not sure in case of fraudolent transfer, who carries the risk (I think it is the customer, but I'm not sure), but I guess it does not matter too much, because even if it is the customer, it would still have a "cost" for the bank in the form of customer satisfaction.

(*) And a final remark about "claiming back money from fraudolent transactions".

Based on previous experience I'm a bit skeptical how/if this really works in reality. As I have written in one of the comments, I once had a fraud-like case, similar to this one. (I.e. car rental company pre-authorizing 100EUR, then charging 100 EUR in a separate transaction, and then just letting the first pre-authorization expire.) 1-2 days after having returned the car, I just noticed that I had 100 EUR less in my balance, but I could not see in net banking what the reason for that was (probably the second transaction was pre-auhtorized, but not yet booked in that moment).

The point of this example is the following: I went to my bank, to find out what happened (I first wanted to know at least who did the second chargement, when and why). They could not tell me this information (they said they don't have access to the card system, or something similar), let alone block the transaction which I believed to be fraudolent. So, all I could do is, based on the amount, guess that this was the car rental company. The bank basically told me to go to the merchant and discuss this issue with them. (And they couldn't nor wanted to do anything about it.)

So, I imagine if once I notice that an amount goes missing from my card (and this time it is 100% fraud), then the bank will just open its arms and say "sorry, we can't do anything about it; try contacting the frauder who mis-used your card".

(Remark: I know, as written above, that this "double charging" (or rather pre-authorizing + charging in a new transaction + letting pre-authorization expire) that car rentals/hotels sometimes do is not considered fraud, and if the bank had told me so (i.e. "sorry, we see that the car rental company charged you twice; this is unfortunate, but not illegal practice"), I would have found this explanation kind of acceptable. What I found worrying is they telling me: 1. we have no idea who/when/why initiated this pending transaction 2. we can't and don't want to do anything to block this suspicious pending transaction.)

So it's all nice and good that transaction information is logged/audited somewhere, and that theoretically the bank bears the risk, but if in practice I can't get back my money in case I did not initiate a transaction, then it is not worth much.

Long story short: I still feel like giving my whole wallet to the merchant, and turning my back, when I enter my card data somewhere ;)