3-D Secure

3-D Secure is an XML-based protocol designed to be an added layer of security for online credit and debit card transactions. It was developed by Visa with the intention of improving the security of Internet payments and offered to customers as the Verified by Visa service. Services based on the protocol have also been adopted by MasterCard, under the name MasterCard SecureCode, and by JCB International as J/Secure. American Express has added SafeKey to UK and Singapore on 8 November 2010.^[1]

3-D Secure adds an authentication step for online payments.

3-D Secure should not be confused with the Card Security Code which is a short numeric code that is printed on the card.

Description and basic aspects of the protocol

The basic concept of the protocol is to tie the financial authorization process with an online authentication. This authentication is based on a three domain model (hence the 3-D in the name). The three domains are:

• Acquirer Domain (the merchant and the bank to which money is being paid).
• Issuer Domain (the bank which issued the card being used).
• Interoperability Domain (the infrastructure provided by the credit card scheme to support the 3-D Secure protocol).

The protocol uses XML messages sent over SSL connections with client authentication (this ensures the authenticity of both peers, the server and the client, using digital certificates).

A transaction using Verified by Visa/SecureCode will initiate a redirect to the website of the card issuing bank to authorize the transaction. Each issuer could use any kind of authentication method (the protocol does not cover this) but typically, a password-based method is used, so to effectively buy on the Internet means using a password tied to the card. The Verified by Visa protocol recommends the bank's verification page to load in an inline frame session. In this way, the bank's systems can be held responsible for most security breaches.

The main difference between Visa and MasterCard implementations resides in the method to generate the UCAF (Universal Cardholder Authentication Field): MasterCard uses AAV (Accountholder Authentication Value) and Visa uses CAVV (Cardholder Authentication Verification Value).

Implementing the protocol

The specifications are currently at version 1.0.2. Previous versions 0.7 (only used by Visa USA) and 1.0.1 have become redundant and are no longer supported. MasterCard and JCB have adopted version 1.0.2 of the protocol only.

In order for a Visa or MasterCard member bank to use the service, the bank has to operate compliant software that supports the latest protocol specifications. Once compliant software is installed, the member bank will perform product integration testing with the payment system server before it rolls out the system.

ACS providers

In 3-D Secure protocol, ACS (Access Control Server) is on the issuer side (banks). Currently, most banks outsource ACS to a third party. Commonly, the buyer's web browser shows the domain name of the ACS provider, rather than banks' domain name, however this is not required by the protocol. Dependent on the ACS provider, it is possible to specify a bank owned domain name for use by the ACS.

MPI providers

Each 3-D secure transaction involves two simple internet request/response pairs: VEReq/VERes and PAReq/PARes. Visa and MasterCard don't license merchants for sending requests to their servers. They isolate their servers by licensing software providers which are called MPI (merchant plug-in) providers.

Merchants

The advantage for merchants is the reduction of "unauthorized transaction" chargebacks. The disadvantage for merchants is that they have to purchase MPI to connect to the Visa/MasterCard Directory Server. This is expensive (setup fee, monthly fee and per-transaction fee); at the same time it represents additional revenue for MPI providers. Supporting 3-D Secure is complicated and, at times, creates transaction failures.

Buyers/credit card holders

The intention behind the system is that cardholders will have a decreased risk of other people being able to use their payment cards fraudulently on the Internet.

In most current implementations of 3-D Secure, the issuing bank or its ACS provider prompts the buyer for a password that is known only to the bank/ACS provider and the buyer. Since the merchant does not know this password and is not responsible for capturing it, it can be used by the issuing bank as evidence that the purchaser is indeed their cardholder. This is intended to help decrease risk in two ways:

1. Copying card details, either by writing down the numbers on the card itself or by way of modified terminals or ATMs, does not result in the ability to purchase over the Internet because of the additional password, which is not stored on or written on the card.
2. Since the merchant does not capture the password, there is a reduced risk from security incidents at online merchants; while an incident may still result in hackers obtaining other card details, there is no way for them to get the associated password.

3-D Secure does not strictly require the use of password authentication. It is said to be possible^{[citation needed]} to use it in conjunction with smart card readers, security tokens and the like. These types of devices might provide a better user experience for customers as they free the purchaser from having to use a secure password. Some issuers are now using such devices as part of the Chip Authentication Program or Dynamic Passcode Authentication schemes^{[citation needed]}.

One significant disadvantage is that cardholders are likely to see their browser connect to unfamiliar domain names as a result of vendors' MPI implementations and the use of outsourced ACS implementations by issuing banks, which might make it easier to perform phishing attacks on cardholders.

Criticism

Verifiability of site identity

The system involves a pop-up window or inline frame appearing during the online transaction process, requiring the cardholder to enter a password which, if the transaction is legitimate, their card-issuing bank will be able to authenticate. The problem for the cardholder is determining if the pop-up window or frame is really from their card issuer, when it could be from a fraudulent website attempting to harvest the cardholder's details. Such pop-up windows or script-based frames lack any access to any security certificate, eliminating any way to confirm the credentials of the implentation of 3-DS.

The "Verified by Visa" system has drawn some criticism,^{[2] [3] [4] [5]} since it is hard for users to differentiate between the legitimate Verified by Visa pop-up window or inline frame, and a fraudulent phishing site. This is because the pop-up window is served from a domain which is:

• Not the site where the user is shopping.
• Not the card issuing bank
• Not visa.com or mastercard.com

In some cases, the Verified by Visa system has been mistaken by users for a phishing scam^[6] and has itself become the target of some phishing scams^[7]. The newer recommendation to use an inline frame (IFrame) instead of a popup has reduced user confusion, at the cost of making it harder, if not impossible, for the user to verify that the page is genuine in the first place. As of 2011, most web browsers do not provide a way to check the security certificate for the contents of an iframe.

Some card issuers also use Activation During Shopping (ADS)^[8], in which cardholders who are not registered with the scheme are offered the opportunity of signing up (or forced into signing up) during the purchase process. This will typically take them to a form in which they are expected to confirm their identity by answering security questions which should be known to their card issuer. Again, this is done within the iframe where they cannot easily verify the site they are providing this information to—a cracked site or illegitimate merchant could in this way gather all the details they need to pose as the customer.

Implementation of 3-D Secure sign-up will often not allow a user to proceed with a purchase until they have agreed to sign up to 3-D Secure and its terms and conditions, not offering any alternative way of navigating away from the page than closing it, thus suspending the transaction.

Cardholders who are unwilling to take the risk of registering their card during a purchase, with the commerce site controlling the browser to some extent, can in some cases go to their bank's home page on the web in a separate browser window and register from there. When they return to the commerce site and start over they should see that their card is registered. The presence on the password page of the Personal Assurance Message (PAM) that they chose when registering is their confirmation that the page is coming from the bank. This still leaves some possibility of a man-in-the-middle attack if the card holder cannot verify the SSL Server Certificate for the password page. Some commerce sites will devote the full browser page to the authentication rather than using a frame (not necessarily an iFrame, which is a less secure object). In this case the lock icon in the browser should show the identity of either the bank or the operator of the verification site. The cardholder can confirm that this is in the same domain that they visited when registering their card, if it is not the domain of their bank.

Mobile browsers present particular problems for 3-D Secure, due to the common lack of certain features such as frames and pop-ups. Even if the merchant has a mobile Web site, unless the issuer is also mobile aware, the authentication pages may fail to render properly, or even at all. In the end, many analysts have concluded that the Activation During Shopping (ADS) protocols invite more risk than they remove and furthermore transfer this increased risk to the consumer.

In some cases, 3-D Secure ends up providing little security to the cardholder, and can act as a device to pass liability for fraudulent transactions from the bank or retailer to the cardholder. Legal conditions applied to the 3-D Secure service are sometimes worded in a way that makes it difficult for the cardholder to escape liability from fraudulent "cardholder not present" transactions.^{[citation needed]}

Limited mobility

When a 3-D Secure confirmation code is required, if the confirmation code is sent by SMS on mobile phone (assuming she/he owns one) the customer may be unable to receive it depending on the country he currently is. (not every mobile network accepts SMS)

See also

• eCommerce
• Secure electronic transaction (SET)
• Merchant plug-in (MPI)

References

1. ^ "SafeKey". AmericanExpress.com. http://about.americanexpress.com/news/pr/2010/safekey.aspx. Retrieved 2010-08-11. 
2. ^ "antiworm: Verified by Visa (Veriphied Phishing?)". Antiworm.blogspot.com. 2006-02-02. http://antiworm.blogspot.com/2006/02/verified-by-visa-veriphied-phishing.html. Retrieved 2010-08-11. 
3. ^ Muncaster, Phil. "Industry lays into 3-D Secure - 11 Apr 2008". IT Week. http://www.itweek.co.uk/itweek/news/2214146/industry-lays-secure. Retrieved 2010-08-11. 
4. ^ Brignall, Miles (2007-04-21). "Verified by Visa scheme confuses thousands of internet shoppers". The Guardian (London). http://www.guardian.co.uk/money/2007/apr/21/creditcards.debt. Retrieved 2010-04-23. 
5. ^ "Verifed by Visa and MasterCard SecureCode: or, How Not to Design Authentication" (PDF). http://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf. Retrieved 2010-08-11. 
6. ^ "Is securesuite.co.uk a phishing scam?". Ambrand.com. http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam/. Retrieved 2010-08-11. 
7. ^ "Verified By Visa Activation - Visa Phishing Scams". MillerSmiles.co.uk. 2006-08-22. http://www.millersmiles.co.uk/report/3279. Retrieved 2010-08-11. 
8. ^ "Activation During Shopping". Visaeurope.com. http://www.visaeurope.com/documents/vbv/verifiedbyvisa_activationduringshopping.pdf. Retrieved 2010-08-11. 

External links

• Visa 3-D Secure Payment Program
• Visa 3-D Secure Specifications
• MasterCard SecureCode home page
• CERIAS discusses Verified by Visa shortcomings
• 3DSecure Explained
• https://usa.visa.com/personal/security/vbv/index.html
• http://www.jsfblog.info/2010/03/3d-secure-and-the-pareq-field-in-google-chrome-safari-browsers/
• http://about.americanexpress.com/news/pr/2010/safekey.aspx