Secure On-Line Credit Card Transactions with
One-Time Pseudo-CVV
Yongdong Wu, and Feng Bao
Cryptography and Security Department Institute for Infocomm Research, A*STAR, Singapore{wydong,baofeng}@i2r.a-star.edu.sg
Abstract—In on-line credit card transactions, the customers often worry about the abuse of credit cards by the mer-chants. This paper proposes a one-time Pseudo-CVV solution which give customers peace of mind by exploiting 2-Factor-Authentication(2FA) channel between the customer and the issuing bank. Because the scheme merely overloads the 2FA infrastructure and does not introduce new hardware, it is cost-effective, user-friendly and easy to deploy.
Index Terms—2 Factor Authentication (2FA), One-time Pass-word, Card Verification Value (CVV)
I. INTRODUCTION
In on-line transactions with credit card, the merchant often ask for the credit card number only without any other further identity verification information. Regretfully, credit cards number can be copied by stealthy employees, or stolen from a merchant’s customer database by hackers over the Internet. Those lost credit card numbers resulted in credit card frauds. For example, it was reported that millions of dollars was lost each year [1], and Molloy et al. [2] stated some fraud cases. As a sequence, many victims blame on-line transactions for such mishaps because of the insecure on-line business form shown in Fig.1. Thus, the insecure business model is perhaps the reason why people shy away from shopping over the Internet [3]. To thwart credit card fraud so as to increase the confidence of credit card holders, Secure Electronic Transactions (SET) protocol [4] was designed to protect credit card information from various attacks in on-line environments. Unfortunately, SET never succeeded in the marketplace because of its high overhead and additional requirement of public key infrastructure (PKI). Therefore, a solution against card-not-present (CNP) fraud should be easy to deploy, low computational cost and economic.
Virtual credit cards1 provide the protection of on-line transactions because a new card number is provided for every transaction under some conditions such as time limits, expiration date, etc. These card numbers may be created with different methods. Hewton’s scheme [5] enables a user to have a smart card containing a plurality of temporary account
1Virtual credit cards are also known as disposable payment cards, tempo-rary credit cards, single-use credit cards, or virtual account numbers.
Fig. 1. An example of on-line credit card payment GUI which is vulnerable to credit fraud. It asks the card holder to submit the credit card number, card holder name and expiration date.
or authentication numbers. Tuchler and Crowe [6] allowed a user to apply for a temporary credit card on-line, and a tem-porary credit card number is issued on-line for immediate use if the electronic application is approved. To be user-friendly, Powell [7] designed a system which automatically inputs the temporary credit card information to on-line credit card purchases while shopping on-line. In nature, virtual credit cards are similar to on-line gift vouchers, whereby consumers intending to shop on-line use their virtual card numbers, just as they would in regular circumstances. Nonetheless, it must be remembered that these cards have several problems. (1) They cannot be carried around like a regular card such that a merchant will have no access to any data apart from the temporary number; (2) In practice, someone complained that about 1/ 3 - 1 /2 vendors refuse CitiBank’s virtual numbers, usually inconsistently for unknown reasons [8]; (3) Because virtual credit cards can only be used for on-line transactions, many card holders feel a need to retain physical cards for use against transactions of some types, therefore, the number of cards the customer has to keep is not reduced; (4) Virtual credit cards are slow in processing transactions as compared to their counterparts.
Dynamic passcode authentication provides an additional layer of security to guard against on-line fraud. Like chip and PIN (Personal Identification Number) in the face-to-face environment, dynamic passcode enables a form of two-factor
authentication (2FA) because it demands the card holder to input an additional username and password for on-line transactions. The Visa PIN Card works by proving that the valid card holder made the transaction as only he/she has the card in their possession and only he/she should know the PIN. For example, Visa-PIN-Card [9], [10] combines a debit or credit chip with technology that generates a secure one-time-only code displayed to the card holder via an integrated eight-digit alpha-numeric screen. However, this solution requires changes to the card acceptance infrastructure, which are not yet commonplace.
Card Verification Value (CVV)2 is the third authentication method to reduce Internet transaction frauds. It requires a card holder to enter the CVV number into the transaction form at transaction time so as to verify that the card is on hand. Since the CVV is not contained on the magnetic stripe of the card, it is not typically included in the transaction when the card is used face to face at a merchant. As a corrupt merchant cannot automatically capture CVV code of a card by scanning the magnetic stripe, it would have to note the CVV visually and record it, which is more likely to arouse the card holder’s suspicion. Additionally, merchants who require the CVV for CNP transactions are forbidden in some countries (e.g., USA) by Visa from storing the CVV once the individual transaction is authorized and completed [11], hence, the probability of credit card information leakage is reduced. Nonetheless, CVV protection cannot defeat phishing scams, where the card holder is tricked into entering the CVV among other card details via a fraudulent website. The growth in phishing has reduced the real-world effectiveness of the CVV as an anti-fraud device [12].
Unlike those schemes such as [13] which generate the virtual credit cards directly, the present scheme generates a Pseudo-CVV code so that the existing on-line applications can be run as usual. The codes can be processed without changing any of the credit card infrastructure currently in place, except the minor changes at the end points, namely, the card users and the card issuers.
The rest of this paper is organized as follows. Section II introduces the basic concepts including CVV and credit card workflow. Those who are familiar with the concepts can skip to Section III which elaborates the Pseudo-CVV. Section IV analyzes the proposed CVV. Section V shows the conclusions.
II. PRELIMINARIES
A. Card Verification Value
CVV is a Message Authentication Code (MAC) calculated from the card’s account number, expiration date and service code with encryption keys known only to the issuing bank (Ref. to http://en.wikipedia.org/wiki/Card security code). It
2VISA refers to the code as CVV, MasterCard calls it CVC2, and American Express calls it CID.
is a three- or four-digit code and printed on the card back shown in Fig.2 during personalisation stage by the bank. Be-cause CVV is hard to extract by card reader, it helps ascertain that the customer placing the order actually possesses the credit card and that the card account is legitimate.
Fig. 2. CVV (number 123 in the circle) is located on the back of credit or debit cards and is typically printed on the right of the sig-nature strip. CVV code is not part of the card number. Adapted from http://en.wikipedia.org/wiki/Card security code.
Although CVV is not mandatory in the on-line trans-actions, the merchants may be forced to do so because transactions without CVV may be charged more than those with CVV, or customers prefer to the merchants demanding for CVV.
B. On-line Credit Card Transactions
For completeness, this Subsection adapts the credit card transaction process from website http://www.authorize.net/ resources/howitworksdiagram/. For a typical e-commerce credit card transaction, a number of participants play key roles in the process with regard to Fig.3. Those players include customer, merchant, payment gateway, acquiring bank’s processor, credit card interchange, the customer’s credit card issuer, and the merchant’s acquiring bank. All of these participants take just 2-3 seconds on average to complete a transaction as follows.
1) After the customer submits his/her credit card infor-mation via a secure channel (e.g., Secure Socket Layer channel, or SSL channel), the merchant forwards a credit card transaction to the Payment Gateway via secure web site connection.
2) The gateway receives the secure transaction informa-tion and passes it via a secure connecinforma-tion to the Merchant Bank’s Processor.
Fig. 3. A generic on-line credit card processing diagram where 7 participants executes 9 steps within a short time (e.g., 2-3 seconds). Adapted from http://www.authorize.net/resources/howitworksdiagram/
3) The Merchant Bank’s Processor submits the transaction to the Credit Card Network (a proprietary system of financial entities that communicate to manage the processing, clearing, and settlement of credit card trans-actions).
4) The Credit Card Network routes the transaction to the Customer’s Credit Card Issuing Bank.
5) The Customer’s Credit Card Issuing Bank approves or declines the transaction based on the customer’s available funds and passes the transaction results back to the Credit Card Network.
6) The Credit Card Network relays the transaction results to the Merchant Bank’s Processor.
7) The Merchant Bank’s Processor relays the transaction results to the gateway.
8) The gateway stores the transaction results and sends them to the customer and/or the merchant.
9) The Customer’s Credit Card Issuing Bank sends the appropriate funds for the transaction to the Credit Card Network, which passes the funds to the Merchant’s Bank. The bank then deposits the funds into the merchant’s bank account. This step is known as the settlement process and typically the transaction funds are deposited into the primary bank account within two to four business days.
III. ONE-TIMEPSEUDO-CVV
A. Model and Requirement
Nowadays, almost all banks provide the on-line services so that the customers are able to perform e-banking or know
his/her bill information timely. To accomplish the financial self-services securely, the customer will build an SSL (Secure Socket Layer) channel according to the digital certificate of the bank. However, few banks check the identities of the cus-tomers based on their digital certificates because it is tedious for most customers to install and maintain the digital certifi-cates. Instead, the banks verify the username/password of the customers. Because the security level of username/password is very low, the customers and the banks have to build 2FA channel so as to confirm the on-line transactions. To this end, a bank may pass a one-time pad such as SecurID token (http: //en.wikipedia.org/wiki/SecurID), a one-time scratch card to the banker user at the time of registration, or send SMS at the time of authentication. In a word, 2FA enables the customer has a temporary ticket which is valid once in a short time. In practice, this 2FA channel is enforced by law in some countries such as Singapore and China. In this paper, we assume that the credit card issuing bank has a mechanism to build a 2FA channel with the card holders.
As indicated in Fig.3, 7 participants are involved in the on-line credit card processing. But this paper will merely care about those who manipulate the credit card information, namely, the customer, the merchant and the issuing bank, and ignore the rest.
An adversary is assumed to be able to obtain credit card numbers, but unable to intercept the 2FA channel, e.g., steal the one-time ticket with trojan horse virus, or eavesdrop the SMS message. With the credit card numbers, the adversary attempts to start credit frauds.
In practice, a new scheme should be compatible with the existing schemes in order to be accepted by the users quickly. For the present Pseudo-CVV scheme, neither the merchant nor the customer are willing to change their on-line habits and/or spend on extra devices. Therefore, a CNP scheme should have the similar infrastructure, operation model and security level as “card present” scheme.
B. The Workflow of Pseudo-CVV
To meet the requirements in Subsection III-A, we should change the existing transaction flow as little as possible.
1) Merchant: In order to obtain the credit card informa-tion, the merchant asking for CVV should provide the input form similar to Fig.4. Exactly, the present scheme keeps the website of the merchant intact.
2) Customer: After a customer selects the goods, he/she inputs the secret information such as credit card number, expiration date, and name into the form shown in Fig.4. To guarantee the secrecy and uniqueness of the transaction, the customer will not key in the CVV printed on the back of the credit card, instead, he/she will use the 2FA ticket (e.g., output of SecurID-like token) as the one-time Pseudo-CVV shown in Fig.5. If the length of the displayed code is longer than the CVV code field, the customer should truncate the
Fig. 4. An example form of on-line credit card payment GUI which asks the customers to input CVV besides the credit card information. This figure is snapped from www.dell.com.
display code, for instance, the first 3-4 bytes into pseudo-CVV, and input pseudo-CVV into the CVV field of Fig.4.
Fig. 5. Pseudo-CVV code generated with SecurID token. Adapted from website http://en.wikipedia.org/wiki/SecurID.
3) Issuing bank: To verify the authenticity of the credit card data forwarded from the merchant, the issuing bank will verify both credit card data and authentication code (either CVV or pseudo-CVV) for CNP. To this end, there are two modules called CVV-verification module and 2FA module. The former takes responsibility to check the authenticity of CVV or pseudo-CVV in credit card transaction, while the latter will check the authenticity of the one-time pass-word in e-banking. In the present scheme, the pseudo-CVV verification is performed due to the collaboration between these two modules. Specifically, if the forwarded code can be confirmed directly by CVV-verification module, the trans-action is carried on as normal CVV-enabled case, otherwise, the CVV-verification module will pass the code to the 2FA module which will subsequently carry on the verification
process as the e-banking case. As long as the pseudo-CVV is authentic, the 2FA module will reply a positive signal to the CVV-verification module, negative signal otherwise. Thus, the issuing bank carries on the subsequent operations as shown in Fig.3.
IV. DISCUSSIONS
A. Security
To simplify the security analysis of the scheme, suppose the Pseudo-CVV is generated from a SecurID token equipped with technology that is synchronized with the issuer and a display that shows the one-time random number. If the number is of 3-4 digits, an adversary can correctly guess the Pseudo-CVV at a probability 0.05% on average. Although the security level is lower than that of virtual card schemes (e.g., [15]–[18]), it is good enough for financial applications given that credit fraud rate itself is not high (e.g., The credit fraud cost is 27 cents per 100 dollars worth of transactions in 2006 [19]).
B. Performance
When a customer likes to pay the goods with a credit card on line, he/she will generate the Pseudo-CVV as the 2FA process, and fill in the payment form with the credit card in-formation and the fresh CVV. Therefore, the Pseudo-CVV scheme is very friendly to the customers because the customers are familiar to the operations, and of high security level.
From the viewpoint of the bank, the deloyment cost is low because the bank does not spend for any equipment and their maintenance, but merely overloads the function of existing devices. The only modification is to build a connection between CVV-verification module and 2FA module, and slightly modify 2FA verification. In all, this modification cost is low.
C. Pseudo-CVV Generator with Handheld Device
There are two popular methods of generating one-time password for 2FA. One is that the service provider directly creates one-time password and sends a one-time password to the user’s registered handphone via out-of-band channel such as SMS. This method is cost-effective but inconvenient for overseas-trip users; another is that the customer generates the one-time password with a dedicated token such as SecurID in Fig.5. The second one is applicable to any one at any time, but it has the following weaknesses:
• the service provider has to spend money in
manufactur-ing, customizing and maintaining the tokens;
• the user must have the token at hand whenever the
transaction is to be done.
• the user may have too many tokens assigned from
• Sometimes, the authentication may fail due to
de-synchronization between customer’s token and bank’s server.
As mentioned in Subsection III-A, we assume that 2FA is available in the on-line transaction. Hence, it is of high probability that the user has a device which is able to run third-party software. This device can be any of smartphone, PDA, iPad, computer etc. Based on this assumption, we propose a Pseudo-CVV generation method which can offer all the benefits of the above two methods. Technically,
• The user downloads a small software from the server’s
website to his/her device.
• The service provider issued a secret to the user via
secure channel, e.g., ATM, SMS, or face-2-face at the registration counter.
• Whenever the CVV is required for on-line transaction,
the customer will activate the software so as to generate a one-time password with the secret, time, or card information (optional), and submit the Pseudo-CVV to the merchant.
• After receiving the fresh Pseudo-CVV code from the
user, the bank will re-construct it with its own data and compare them. Only if both are identical, the issuing bank will authenticate the customer, and approve the transaction.
In this new generator, since the secret can be shared by different devices nd or users, the scheme is convenient for the customers to generate the Pseudo-CVV by family members. Although the generator may de-synchronize with the bank sometimes, the customer can adjust the time easily.
V. CONCLUSIONS
Unlike “card present” transactions which must be car-ried on in face-to-face environment, CNP transactions are applicable in cyberspace and very suitable to e-business. But CNP business faces more security challenges than its counterpart, namely, credit frauds. This paper presents a one-time Pseudo-CVV solution to thwart credit frauds assume that the customer has a 2FA authentication channel with his/her issuing bank.
Not only is the present scheme extremely user-friendly to operate, it also offers issuing banks with a secure solution to better authenticate on-line transactions while increasing the customer’s confidence when shopping over the Internet without the need for a separate device. Moreover, its imple-mentation is very easy, fast and low cost for issuing banks.
REFERENCES
[1] “Internet Fraud Statistics Reports,” http://www.fraud.org/internet/ intstat.htm
[2] Ian Molloy, Jiangtao Li, Ninghui Li, “Dynamic virtual credit card numbers,” International Conference on Financial cryptography and 1st International conference on Usable Security, Lecture Notes In Computer Science 4886, pp.208-223, 2007.
[3] Harish D Shenoy, “What is a Virtual Credit Card?” http://EzineArticles. com/?expert=Harish D Shenoy, access on Jul. 29, 2010.
[4] “Secure Electronic Transaction,” http://en.wikipedia.org/wiki/Secure Electronic Transaction
[5] Alfred Hewton, “Smart card with random temporary account number generation,” US Pat. No. 20080201265, 21 Aug. 2008.
[6] James Tuchler, Andrew Crowe, “Methods and apparatus for allowing internet based purchases based on a temporary credit card number,” US Patent No. 6,980,969, 27 Dec. 2005.
[7] Brian Powell, “Automatic generation of temporary credit card infor-mation,” US Patent No. 7,664,699, 16 Feb. 2010.
[8] Lucy Lazarony, “Virtual credit card programs,” http://www.bankrate. com/brm/news/cc/20021011b.asp
[9] Visa Europe, “Dynamic passcode authentication: overview guide,” http://www.visaeurope.es/documents/aboutvisa/ dynamicpasscodeauthentication.pdf?d=070207, Access on 31 Jul. 2010.
[10] Visa Europe, “Visa’s innovative PIN Card pilot brings step change to tackling CNP fraud,” Latest news from Card Academy, Issue 10, June 2008. http://www.rixtar.com/files/card academy/Card Academy Bulletin-ISSUE-102008.pdf, accessed on 31 Jul. 2010.
[11] PT, “Shop Safely on-line: Use a Virtual Credit Card Number Credit Cards,” http://ptmoney.com/2010/04/27/ shop-safely-on-line-use-a-virtual-credit-card-number/
[12] Ryan Paul, “Security researchers blast credit card verification system,” Last updated January 28, 2010, http://arstechnica.com/security/news/ 2010/01/security-researchers-blast-credit-card-verification-system.ars [13] Yingjiu Li, and Xinwen Zhang, “Securing credit card transactions
with one-time payment scheme,” Electronic Commerce Research and Applications, 4(4):413-426, 2005.
[14] Kerry Murdock, “Credit Card Processing: How It All Works,” April 01, 2006, http://www.practicalecommerce.com/articles/ 168-Credit-Card-Processing-How-It-All-Works
[15] Francesco Buccafurri, and Gianluca Lax “A Light Number-Generation Scheme for Feasible and Secure Credit-Card-Payment Solutions,” E-Commerce and Web Technologies, Lecture Notes in Computer Science (LNCS) 5183, pp.11-20, 2008.
[16] Dong Shin Suh, “Method and system for providing temporary credit card number on internet,” WO 2002005165 A1, 17 Jan. 2002 [17] Aviel D. Rubin, and Rebecca N. Wright, “On-line generation of
limited-use credit card numbers,” International Conference on Finan-cial Cryptography, LNCS 2339, pp. 196-209, 2001.
[18] Adi Shamir, “SecureClick: a Web payment system with disposable credit card numbers,” International Conference on Financial Cryptog-raphy, LNCS 2339, pp.232-242, 2001.
[19] Ken Paterson, “Credit Card Issuer Fraud Management, Report High-lights, December, 2008”. Mercator Advisory Group, 2008. http://www. sas.com/news/analysts/mercator fraud 1208.pdf
[20] “Method to acquire a temporary credit card number,” http:// priorartdatabase.com/IPCOM/000032317.
