Beautiful Trade/3-D Secure

From WikiContent

Revision as of 02:19, 30 June 2009 by Ebellis (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

3-D Secure

3-D Secure is an XML-based protocol created by Visa to authenticate the consumer to the card. Visa, MasterCard, and JCB International have adopted the protocol under the names Verified by Visa, MasterCard SecureCode, and J/Secure, respectively. 3-D Secure transactions

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:

1. The shopper connects to a merchant’s site, makes a purchase selection, and enters card details.

2. The Merchant Server Plug-in (MPI) sends the Primary Account Number (PAN) to the Directory Server.

3. The Directory Server queries the appropriate Access Control Server (ACS) to determine whether authentication (or proof of an authentication attempt) is available for the Primary Account Number. If no appropriate Access Control Server is available, the Directory Server creates a response for the MPI and processing continues with step 5.

4. The Access Control Server responds to the Directory Server.

5. The Directory Server forwards the Access Control Server response (or its own) to the MPI. If neither authentication nor a proof of authentication attempt is available, 3-D Secure processing ends, and the merchant, acquirer, or payment processor may submit a traditional authorization request, if desired.

6. The MPI sends a Payer Authentication Request (PAR) to the Access Control Server.

7. The Access Control Server receives the Payer Authentication Request.

8. The Access Control Server authenticates the shopper using processes applicable to the Primary Account Number (PAN), which may involve a password, chip, PIN, etc. Alternatively, the Access Control Server may produce a proof of authentication attempt.

9. The Access Control Server then formats the Payer Authentication Response message with appropriate values and signs it.

10. The Access Control Server returns the Payer Authentication Response to the MPI in order to cache the response for use in further transactions. The Access Control Server can send selected data to an Authentication History Server (AHS).

11. The MPI receives the Payer Authentication Response.

12. The MPI validates the Payer Authentication Response signature (either by performing the validation itself or by passing the message to a separate Validation Server).

13. The merchant proceeds with an authorization exchange with the acquirer. 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.

Evaluation of 3-D Secure

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.

Personal tools