-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/01/2010 09:31 AM, Anne & Lynn Wheeler wrote:
> Part of what was recognized by the x9a10 financial standard working
> group (and the resulting x9.59 financial standard) was that relying
> on the merchant (and/or the transaction processor) to provide major
> integrity protection for financial transactions ... is placing the
> responsibility on the entities with the least financial interest
> ... the "security proportional to risk" scenario (where largest
> percentage of exploits occur in the current infrastructure
> ... including data breaches)
Speaking as a merchant (yep, I get to do that too!), albeit one in
Higher Education, we don't view the risk of a compromise of a
transaction simply as the risk of losing the associated profit. Our
risk concern is more about risk to reputation. MIT wants it's name in
the papers associated with scientific breakthroughs and the like, not
with reports of security breaches!
We also need to be concerned with penalties that might be levied from
the various card networks (this is a more recent concern).
I am involved in our PCI security efforts (led them for a while). We
are not at all concerned with issues involved with SSL. Almost all of
our concern is about protecting the PC's of non-technical people who
are processing these transactions.
Similarly the breaches I am aware of were all about compromising
back-end systems, not breaking SSL.
> A decade ago, there were a number of "secure" payment transaction
> products floated for the internet ... with significant upfront
> merchant interest ... assuming that the associated transactions
> would have significant lower interchange fees (because of the
> elimination of "fraud" surcharge). Then things went thru a period of
> "cognitive dissonance" when financial institutions tried to explain
> why these transactions should have a higher interchange fee ... than
> the highest "fraud surchange" interchange fees. The severity of the
> "cognitive dissonance" between the merchants and the financial
> institutions over whether "secure" payment transactions products
> should result in higher fees or lower fees contributed significantly
> to the products not being deployed.
I remember them well. Indeed these protocols, presumably you are
talking about Secure Electronic Transactions (SET), were a major
improvement over SSL, but adoption was killed by not only failing the
give the merchants a break on the fraud surcharge, but also requiring
the merchants to pick up the up-front cost of upgrading all of their
systems to use these new protocols. And there was the risk that it
would turn off consumers because it required the consumers setup
credentials ahead of time. So if a customer arrived at my SET
protected store-front, they might not be able to make a purchase if
they had not already setup their credentials. Many would just go to a
competitor that doesn't require SET rather then establish the
credentials.
So another aspect of the failure of SET was that it didn't provide
real incentives for consumers to go though the hassle of having their
credentials setup, thus creating a competitive advantage for those
merchants who did *not* use SET. Sigh.
Comes back to Perry's theses, you *must* design security systems to
work for *real* people (both as consumes and merchants).
-Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFMVbQg8CBzV/QUlSsRAlCwAKDL85NXtQ+HXMvjvhpBs3fnOiL+0wCghXTT
aILxpWKCSavrIDukc+VCKVU=
=tATX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
