Beautiful Trade/Ecommerce Redone

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: '''E-Commerce Redone: A New Security Model''' By reviewing the current security model for e-commerce transactions, we now have a good feel for both its strengths and its weak points. No...)
Current revision (13:25, 30 June 2009) (edit) (undo)
Line 59: Line 59:
perfected (easier said than done).
perfected (easier said than done).
'''Requirement 4: Authentication Data Should Not Be Shared Outside of
'''Requirement 4: Authentication Data Should Not Be Shared Outside of Authenticator and Authenticated'''
Authenticator and Authenticated'''
Our fourth requirement for a secure e-commerce transaction is not to share authentication
Our fourth requirement for a secure e-commerce transaction is not to share authentication

Current revision

E-Commerce Redone: A New Security Model

By reviewing the current security model for e-commerce transactions, we now have a good feel for both its strengths and its weak points. Now I would like to propose a more elegant way to look at e-commerce security that renders the value of card account information useless to attackers and brings assurance to consumers.

When conducting a credit or debit transaction in a card-not-present use case, there are essentially seven base requirements that will ensure the transaction is secure while keeping the system usable for both consumers and merchants.

Requirement 1: The Consumer Must Be Authenticated

The first requirement is to authenticate consumers to ensure they are who they say they are. If consumer John is tied to credit account John123, we must first know this is indeed consumer John. So who is the best party and what is the best method to perform this authentication? The best party is the manager of the cardholder’s account, which is the issuing bank in most cases. This is for several reasons: the issuer already has the information, so storing it with them does not add another point of failure to the system; also, they have the most resources to invest in the expertise and processes to do authentication properly; finally, there are much fewer issuers than there are other actors.

This authentication may be handled through a combination of any of the three classic factors of authentication:

• Something the consumer knows, such as a password.

• Something the consumer has, such as a token or certificate.

• Something the consumer is, such as biometric data.

As we will see later, the latter two may add complexities to mass distribution and management.

Requirement 2: The Merchant Must Be Authenticated

The second requirement is to authenticate the merchant. This gives the consumer assurance that the merchant is legitimate and is providing the goods and services ordered by the consumer. Similar to the first requirement, the optimal party for authenticating the merchant is the manager of the merchant’s account—in most cases, the acquiring bank.

OK, so we have authenticated both the consumer and the merchant, but now we hit a challenge. The issuer and the acquirer have performed authentication, but the transaction is being initiated between the consumer and merchant. How do we share this authentication so that the two primary actors in this use case have verification of each other’s authenticity? We need the issuer and the acquirer to communicate this verification in a secure manner. I will go into more detail on this topic when I lay out the proposed process.

Requirement 3: The Transaction Must Be Authorized

This brings us to the third requirement: the transaction itself must be authorized. So far we have determined that consumer John is indeed consumer John and tied to consumer John’s account. We have verified that merchant Vencer Corp is a legitimate merchant tied to an acquiring bank. We now need to know that consumer John is authorized to make this purchase.

The third requirement, luckily, has not raised problems in e-commerce, provided the consumer is properly authenticated. The issuing bank can confirm the appropriate approvals for this transaction based on all the existing systems in place for account status, credit limits, etc. Thus, fraud from an intruder (often called “hostile fraud”) can be prevented if requirement 1 is perfected (easier said than done).

Requirement 4: Authentication Data Should Not Be Shared Outside of Authenticator and Authenticated

Our fourth requirement for a secure e-commerce transaction is not to share authentication data outside of the party being authenticated (in our case, either the consumer or the merchant) and the party responsible for the authentication. In a typical card-not-present transaction, these are four different entities. A consumer (1) should be authenticated by an issuing bank (2), while a merchant (3) is authenticated by its acquiring bank (4). The real trick here is sharing the verification of a successful or unsuccessful authentication among all of these parties without sharing the actual credentials.

Admittedly, e-commerce systems can suffer from what is called (in a contradiction of terms) “friendly fraud,” which means fraud from the very person with whom the merchant wants to transact. Friendly fraud occurs when a consumer experiences a change of heart after the purchase or simply refutes legitimate charges. Detecting friendly fraud pre-transaction is more difficult than detecting hostile fraud. There may be ways to bring friendly fraud down to a more acceptable volume through digital signatures, but that’s beyond the scope of this chapter.

Unlike today’s model with its (widely) shared secret, our new model must be able to share the consumer’s and merchant’s authentication status without sharing their credentials. If we accomplish this, breach of data at the merchant about the consumer’s authentication status has no impact on the consumer’s credit account. Consumers could then rely on the security of the issuing bank’s system, not the security of every merchant from which they have ever made a purchase.

Merchants are typically authenticated by this kind of single provider system, where the provider is the acquiring bank. Since the acquiring bank authenticates the merchant, my model shares this authentication status with the consumer prior to that transaction. As we will see later, I propose this should be handled between the acquirer and the issuer across the card networks.

Requirement 5: The Process Must Not Rely Solely on Shared Secrets

The fifth requirement simply repeats the central message of this chapter. The new model must not break if a merchant or service provider is compromised. Virtual card account numbers, discussed earlier, are a good way to meet this requirement—but it must become universal. When provided with nothing but one-time or limited-use accounts, a compromise at a single merchant or service provider will not break the overall e-commerce authentication model.

Requirement 6: Authentication Should Be Portable (Not Tied to Hardware or Protocols)

Portability is a must because there is simply too much infrastructure and too many systems currently in place to expect a massive redeployment or overhaul. We must build a model that allows for consumer and merchant authentication within the existing payment frameworks and networks.

Although SET provided a robust set of security controls and met most of the requirements mentioned so far, this area is where it fell short. Adding the extra overhead of a PKI infrastructure and process proved to be too much for the current payment process.

Requirement 7: The Confidentiality and Integrity of Data and Transactions Must Be Maintained

Our seventh and final requirement—to maintain confidentiality and integrity of data and transactions—is a no-brainer and a must for our new model to be taken seriously. This includes all authentication data, transaction and order data, and any data maintaining the state of any of these. This requirement must be adhered to as this data is transmitted across networks and stored throughout these systems.

Personal tools