The name 3-D Secure refers to the three domains involved in the security model. The first domain, the acquirer, is essentially the e-commerce merchant or acquiring bank. A merchant, using compliant software, makes a call to the issuing bank (the second domain, or issuer) to verify that the account holder (the third domain) is enrolled in the 3-D Secure card program. If the cardholder is enrolled, the issuing bank collects a PIN or password directly from the account holder via a frame on the merchant’s web page. This authentication protocol is transmitted in an XML document over Secure Sockets Layer (SSL). The SSL ensures confidentiality of the account holder’s PIN or password and the authenticity of both the host and client. At the same time, the PIN or password is not available to the merchant or acquiring bank, keeping this data confidential to only the account holder and her issuing bank. The procedure, while complex to describe, is a familiar third-party trust scenario:

Following step 13, the acquirer processes the authorization with the issuer via an authorization system such as VisaNet, and then returns the results to the merchant.

3-D Secure has some nice features for authenticating the user to the account, as well as due diligence on the merchant side to ensure it is registered with the card brands; uses compliant payment software; and maintains an active, legitimate merchant account with an acquiring bank. But it has proven unwieldy in practice.

Phishing concerns have been a persistent issue with 3-D Secure. On the one hand, some phishers mimic its behavior. On the other hand, some users reject authentic 3-D Secure transactions as phishing attempts. This has to do with the somewhat out-of-band nature of the PIN authentication, since the request is coming from a different domain than the merchant, and the fact that the issuing bank and the DNS name may not be recognized by the consumer.

A more fundamental security problem in 3-D Secure is that, just like the CV2 number described in the previous section, it is not mandatory for all transactions. So the customer’s account number is still a valuable shared secret. All of the same precautions must go into protecting the Primary Account Number as it makes its way through the various merchant, payment, and supplier systems.

Precertification requires a notable overhead in setting up the protocol between the merchant, the bank, and the consumer. Although the overhead is significantly less than what we will see in our analysis of the SET protocol in the next section, it’s still not ideal.

Beyond the phishing complaint of some 3-D Secure consumers lies a liability issue. The card brands that support 3-D Secure have stated they will not hold merchants liable for fraudulent transactions run through 3-D Secure. This is a great incentive for the merchant to implement 3-D Secure, but moves the requirement of proof of a fraudulent transaction to the consumer, an area where the consumer previously had little liability. Since 3-D Secure is not foolproof, this may not go over very well with cardholders. It essentially places blame for a successful phishing attack on the victim.

The sequence of events required for a transaction follow:

Unfortunately, due to the amount of overhead involved in the massive Public Key Infrastructure (PKI) and registration process required by SET, it will never be widely adopted. The complexities with managing it become unbearable given the size of the e-commerce market.

Each supplier differs slightly in its implementation of virtual cards, but there are essentially two variants: single-use and multiple-use virtual cards. Both types are usually generated “on the fly” via a cardholder request. An existing card account holder requests a virtual card from her virtual card provider for use on a particular e-commerce site. The provider supplies the account holder with a virtual card number, including an expiration date and CV2 security code.

A single-use card can be used for a single transaction involving a limited payment. These cards typically expire in a matter of weeks or less and can be used only with the merchant designated during the cardholder’s request. Thus, lost or stolen information rapidly becomes invalid and worthless to the attacker.

Multiple-use virtual cards are also available through many virtual card providers. These allow for use cases where recurring charges apply, such as paying a monthly bill. Multiple-use cards still carry with them many of the security features of their single-use equivalents, such as being valid with a single merchant and containing limited monthly charge caps. If a multiple-use virtual card is lost or stolen, an attacker could use the card only at that merchant and only for the authorized amount of the recurring charge. This mitigates a great deal of fraud.

It’s often assumed that consumers guard their credit card information with care because they have the most to lose when it’s abused, but because of existing regulation to control some of these externalities, this is not actually the case. In the United States, a consumer is liable only for the first $50 of any fraud committed against his account. Typically, the issuing bank will also waive the $50 requirement in order to keep its customer base happy.

Therefore, while most consumers express a desire to protect their account numbers, security codes, and expiration dates, in the heat of a purchase there is actually very little incentive for the consumer to hold back the information. The incentives that do exist are not financial as much as saving the time and hassle associated with a compromised card.

As a point of comparison, there is a greater consumer incentive to protect a debit card, because the consumer is not protected by the same regulations as with credit cards. Also, debit cards are often tied directly to consumer checking and savings accounts, causing an immediate financial hit to the consumer upon a debit card security compromise.

In the existing model, the merchant actually has quite a bit to lose in case of a breach. A compromise of cardholder data can lead to consequences related to both regulations and liability. The merchants are regulated by the card associations via the Payment Card Industry, which imposes a security standard that merchants must adhere to when handling data, along with the systems and networks that contains and transmit it. A merchant found in breach of this standard suffers both financial and operational penalties, enforced by the card associations. Financial penalties are often assessed against the acquiring bank, which in turn passes those fines on to the merchant. Merchants can also be found liable and sued by the issuing banks, indemnifying the banks for any costs associated with a breach, including the cost of reissuing cards.

Merchants also bear the financial responsibility of accepting fraudulent cards used to make purchases within their environment (except when using 3-D Secure). A merchant must put a number of fraud-detection systems in place in order to ensure that the card being used is valid and is wielded by the assigned cardholder. If a merchant ends up accepting a fraudulent card, the issuing bank issues a chargeback, refunding the consumer’s account. If the merchant has already processed the transaction and provided the product or service, it has to absorb the loss associated with that transaction.

Although the merchants have a lot of incentive to protect this information, they do not control enough of the purchase process to do so effectively. As noted earlier, this data must pass through multiple systems, including systems outside the merchant’s direct control. We also saw that many merchants hold on to some of this data long after the transaction, adding further risk.

Service providers are also regulated by the PCI Data Security Standard (DSS). According to the PCI Security Council, the definition of a service provider is a:

Many of the same rules that apply to merchants also apply to service providers, who have similar penalties and liabilities. Their incentives are not quite the same, however, as they do not have direct interaction with the consumer. That said, brand damage could still be a large factor within the business-to-business space.

The acquiring (merchant) bank and issuing banks are heavily regulated entities whose requirements for information protection go well beyond the Payment Card Industry. The issuing bank has an added incentive of representing the consumer in this transaction. This usually means it not only looks to protect this data, but often serves as an advocate to its customer. The merchant bank, while regulated by many of the financial laws and exchanges, usually serves as a middleman or pass-through and is therefore implicated in the penalties associated with merchants and service providers. When a merchant or one of its service providers is believed to have been breached, the acquiring bank will pass on any fines assessed by the card associations to these groups, since they directly manage the relationship with the merchant.

The card association’s primary incentive to prevent fraud is brand protection. Simply stated, excessive breaches of a given brand could taint the image and lower the use of its network. The financial consequences of a breach to the card associations are not necessarily tangible. The card associations mainly want consumers to feel safe when shopping with their card. The PCI DSS was formed by several card brands that combined their security programs in an attempt to self-regulate and protect their brand.

Overall, each player within a transaction carries some incentive to protect this data (ironically, the consumer has the least). But significantly, the incentives do not directly align with who has control. That is, no single player can completely control the protection of the data, nor do the parties have incentives commensurate with their control over the protection of the shared secret as it travels through the various environments.

The current system simply has too many parties that require knowledge of this shared secret with inadequate incentives to expect the information to remain confidential throughout its life. Multiply the generic diagram of a single transaction in Figure 5-1 by the number of transactions throughout the life of a card, and you’ll see that thousands of data handlers are often handed care of a single shared secret.