<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/css" href="http://commons.oreilly.com/wiki/skins/common/feed.css?97"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>Beautiful Trade/Weak Amelioration Attempts - Revision history</title>
		<link>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Weak_Amelioration_Attempts&amp;action=history</link>
		<description>Revision history for this page on the wiki</description>
		<language>en</language>
		<generator>MediaWiki 1.11.0</generator>
		<lastBuildDate>Wed, 22 May 2013 11:05:48 GMT</lastBuildDate>
		<item>
			<title>Ebellis: New page: '''Weak Amelioration Attempts'''   To address the problems associated with shared secrets among large groups of people, the card  associations came up with the concept of a security code (...</title>
			<link>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Weak_Amelioration_Attempts&amp;diff=24534&amp;oldid=prev</link>
			<description>&lt;p&gt;New page: '''Weak Amelioration Attempts'''   To address the problems associated with shared secrets among large groups of people, the card  associations came up with the concept of a security code (...&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;'''Weak Amelioration Attempts''' &lt;br /&gt;
&lt;br /&gt;
To address the problems associated with shared secrets among large groups of people, the card &lt;br /&gt;
associations came up with the concept of a security code (CV2), a three- or four-digit number &lt;br /&gt;
printed on the card. This is used as a pseudo-second factor for authentication, attempting to &lt;br /&gt;
prove the purchaser has the card in her possession.&lt;br /&gt;
 &lt;br /&gt;
There are two weaknesses in this patch to the system. First, the security code becomes an &lt;br /&gt;
additional shared secret. There are specific rules around handling security codes for merchants &lt;br /&gt;
and service providers, but again we rely on the weakest link in the purchase path. Second, not &lt;br /&gt;
all banks currently support this code, nor is it required in all cases. This means there is little &lt;br /&gt;
incentive for the merchant or acquirer to reject a purchase based on a failed check of this code. &lt;br /&gt;
Thus, the security code offers minimal improvement to the anti-fraud system. &lt;br /&gt;
&lt;br /&gt;
While CV2 attempts to authenticate the consumer, we still lack authentication for the &lt;br /&gt;
merchant. How does the purchaser know the merchant is legitimate? What prevents &lt;br /&gt;
consumers from being socially engineered or phished out of their payment data? &lt;br /&gt;
&lt;br /&gt;
The card associations and third-party payment providers have created additional security &lt;br /&gt;
programs to authenticate and authorize payments in card-not-present situations. Let’s analyze &lt;br /&gt;
a few of the more common processes in place today in order to assess what is working and any &lt;br /&gt;
areas that may be flawed.&lt;/div&gt;</description>
			<pubDate>Tue, 30 Jun 2009 02:16:09 GMT</pubDate>			<dc:creator>Ebellis</dc:creator>			<comments>http://commons.oreilly.com/wiki/index.php/Talk:Beautiful_Trade/Weak_Amelioration_Attempts</comments>		</item>
	</channel>
</rss>