In Europe most cards use a chip+pin system to secure the card information. You put the card in te machine and enter a PIN number to decrypt the card information which is stored on the chip. Theoretically this is more secure as the credit card number alone is not enough to make transactions: you still need the PIN.

How does this work swirly when you want to set up a recurring transaction eg. your phone bill? I presume that you do not give your pin to the phone company.


There is a difference between using your CC on a machine (ATM, PoS) and online.

On a machine you will be identified by the CC number and PIN. If you are using card with a magnetic strip - it can be easily cloned. If you are using chip card, then it's safer, because machines can not read the chip, they can only interact with it and ask it to verify if the pin is correct or not and the chip will answer only "yes" or "no". In essence chip is like a little computer, that is specifically designed to be tamper proof (even on physical level - it's encased in a special epoxy and disassembling it without breaking something is quite difficult).

When shopping online PIN is not used for indentification. Other pieces of information are used to verify that you are who you are, like the numbers on the back of the credit card, your full name, billing address, phone number, email address.


There is a distinction which must be made between the account and the card.

In countries where debit/credit cards have chips, things go the following way when paying in a shop or restaurant:

  • The merchant/waiter shows a payment terminal to the customer.
  • The customer inserts his card into the terminal. Half of the card still sticks out; only the chip is used (the magnetic stripe is not read).
  • The chip, once electrically powered, announces to the terminal its identity, i.e. (mostly) the account number to which this card is linked. The data packet containing the identity is signed (with an actual digital signature algorithm like RSA) by the bank; this allows the terminal to assume that the identity really exists.
  • The terminal asks for the PIN. The users enters the PIN.
  • The terminal sends PIN and transaction details (amount, merchant ID) to the card.
  • The card verifies the PIN and, if correct, "signs" the transaction details; that "signature" may be in fact a MAC computed with a secret key that is also known to the bank. The payment terminal cannot verify this "signature"; it just stores it, to send to the bank at a later date.

In this process, a considerable amount of trust is implied:

  • Cards can be "cloned": it suffices for the fake card to send the same "identification packet" as the genuine card; then, when the fake card is supposed to verify the PIN and compute the MAC on the transaction, the card simply says "PIN is good" and sends some random gibberish. The expression "yes-card" has been coined to describe such a card.

    Two workarounds have been deployed for this kind of attack: one of them is the physical appearance of the card. Genuine cards are full of colours and iridescent graphical elements that the merchant/waiter is supposed to visually check (that's about the same kind of method as for banknotes). The other workaround is to make the terminal do an online check with the bank while the transaction is ongoing (systematically if the amount is beyond some threshold; randomly otherwise). In recent years, terminals with WiFi or 3G capabilities have made this process a lot smoother.

  • The customer must believe that the amount displayed on the terminal screen is indeed what will be sent to the card, and, similarly, that the terminal will not try to record the PIN. Current terminals are in fact big smart cards, in that they are tamper-resistant and can contain secret values that they will actively destroy if their case is opened.

    Main workaround for that kind of attack is classical police. If too many frauds are reported involving a specific shop, then mean-looking law enforcement agents are liable to invest the premises and dispense discomfort to the merchant. Other workarounds may imply a kind of recognition step by which the terminal somehow proves its quality of being a genuine terminal to the card.

The steps above are likely to vary, depending on country, bank, and time. As a rule, banks cultivate secret on their protocols. One point is that, for a long time, smart cards were not powerful enough to generate true signatures (e.g. RSA) on the fly (expensive cards have been able to do that for two decades, but banks usually take issue on that nasty word, and credit cards are normally of a much cheaper persuasion).

For all their shortcomings, smart cards have reputedly divided fraud rates by about 10, which means a lost of money saved, and thus banks were quite happy about it. North American banks have long craved for these savings, but they waited for the relevant patents to expire (which is why US and Canada banks seem to have "discovered" the new technology of smart cards around 2006: the core patent was from 1986, and patents last 20 years).

The important point: all the payment process is about a bank order to be sent to the bank. The merchant wants the customer's bank to take some money from the customer's account, and send it to the merchant's bank, for deposit in the merchant's account. The smart card really acts as an authentication device which is used to demonstrate to the customer's bank that the said order incarnates the customer's wishes.

Now let's see what happens when shopping online. What you enter in the browser fields is certainly not the chip; in fact, you just type some digits which are printed on the card surface. The Web server has no way to know whether the human user really has the card in his hands at that point, of just the digits themselves. These digits are assumed to be somewhat secret.

This kind of transaction also results in a bank order. In this case, the authentication protocol is quite flimsy: with the card number, card holder's name, expiration date and CVV, the merchant can somehow prove to the bank that the customer was involved at some prior date; but the banks have to trust the merchant for sending the true amount. It so happens that most merchants are honest. The fraud rate is still high and, indeed, banks would be quite happier if there was a way for the card chip to be involved in such transactions.

For the question here, the conceptual point is that the transaction is indeed about the bank accounts. A card chip, the card number and CVV, a check with a handmade signature... are all authentication elements which are used by banks to try to detect most fraud attempts (and gather legal elements to retaliate on fraudsters). When a transaction occurs, be it "one-time" or "recurring", it really is a set of actions on the bank side; the tangible card is only involved early in the process, possibly in a very indirect way (e.g. when you send the card number over a phone call or a Web site, the card is merely used as a transport medium for a few digits), and for mere "authentication".

Cards being a system proposed by banks and managed by banks, the security systems related to card management really are about protecting the bank, not the customer or the merchant. Banks thing big, and they think in financial terms. Banks are not interested in achieving ultimate security; banks really want to achieve the optimal balance between fraud rates and costs. For instance, to use smart cards for online transactions, there must be a card reader on the customer side; preferably a reader which includes a display and a PIN pad, because the host computer could be under hostile control (malware exists). Distributing readers to every customer is likely to be very expensive, which explains why banks don't do it. Also, new protocols and process can really be applied only if a large majority of banks and merchants agree to switch, and won't deploy faster than customer's cards are renewed, so one can expect things to change slowly, when they change at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.