Ebellis at 13:25, 30 June 2009

Ebellis — Tue, 30 Jun 2009 13:25:18 GMT

←Older revision		Revision as of 13:25, 30 June 2009
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

Ebellis: 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...

Ebellis — Tue, 30 Jun 2009 03:07:51 GMT

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...

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. 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.

Beautiful Trade/Ecommerce Redone - Revision history

Ebellis at 13:25, 30 June 2009

Ebellis: 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...