<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Merchant Account Blog &#187; Data Security</title>
	<atom:link href="http://www.merchantequip.com/merchant-account-blog/category/data-security/feed" rel="self" type="application/rss+xml" />
	<link>http://www.merchantequip.com/merchant-account-blog</link>
	<description>Merchant Accounts, Ecommerce, Processing Equipment</description>
	<lastBuildDate>Wed, 18 Jan 2012 15:32:56 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Zappos Breach &#8211; All is well, no credit card data was stolen&#8230;</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen#comments</comments>
		<pubDate>Wed, 18 Jan 2012 15:32:56 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Ecommerce]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantequip.com/merchant-account-blog/?p=1603</guid>
		<description><![CDATA[The online retailer Zappos just had a data security breach where they lost 24 Million customer&#8217;s personal information records. This loss included names, addresses, email and phone numbers, encrypted passwords, but did not include credit card information. No doubt that thoughtful security planning prevented the loss of credit card or financially sensitive information. However, it [...]]]></description>
			<content:encoded><![CDATA[<p>The online retailer Zappos just had a data security breach where they <a href="http://www.informationweek.com/news/security/attacks/232400441">lost 24 Million customer&#8217;s personal information records</a>. This loss included names, addresses, email and phone numbers, encrypted passwords, but did not include credit card information.</p>
<p>No doubt that thoughtful security planning prevented the loss of credit card or financially sensitive information. However, it doesn&#8217;t really lessen the reality that the repercussions from the Zappos breach could be huge. Does data security go far enough if we accept that personal information is completely acceptable to be lost as long as financial information is not?</p>
<p><img class="alignright size-full wp-image-1604" title="iStock_000017590354XSmall" src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2012/01/iStock_000017590354XSmall.jpg" alt="" width="359" height="334" />With the amount of personal information that was obtained in the Zappos breach, the thieves have a very lucrative marketing or hacking information package.</p>
<p><strong>On the marketing side</strong></p>
<p>Companies pay a lot of money for targeted marketing lists like the one that Zappos inadvertently provided. Let&#8217;s see, here&#8217;s a list of 24 million people that definitely buy things online, most likely shoes or clothing items, FIRE AWAY&#8230;</p>
<p>This information is a telemarketer or direct marketer&#8217;s dream, and they can target these known shoppers via phone, mail, and email.</p>
<p><strong>On the hacking side</strong></p>
<p>I can almost guarantee that Zappos customers are going to receive an onslaught of highly engineered spam, viruses, offers, and everything else to their emails. At the same time they are going to start getting physical spam, and scam offers, and probably are going to see telemarketing scams as well. There&#8217;s really no limit to how the information can be used for malicious purposes. Scam companies and hacking groups trying to install mallware and spyware are extremely efficient and proficient at developing well planned attacks on unsuspecting users. There are millions of computers called zombie computers because they are being used to send spam and other malicious activities without the knowledge of their owners. Expect some more.</p>
<p>As to the encrypted passwords. Websites typically use 1-way hashing mechanisms for password storage. This means that the password is encrypted, but cannot be decrypted by any reasonable means. The caveat to this is that if the hacker knows how the password was hashed, they can create a huge list of hashes and compare them to find the original. This is a very targeted attack, but with 24 million passwords it&#8217;s worth a lot of effort. They will begin finding real password very quickly if they discover the hashing mechanism. Since many users do not use unique passwords between websites, the direct loss from being able to log into user&#8217;s bank accounts, or other websites will be significant. I always recommend using a unique password with every site you log into, and <a href="http://www.roboform.com/php/land.php?affid=jeste&amp;frm=frame1">use a password manager like roboform</a>.</p>
<p><strong>The reality</strong></p>
<p>The reality of this situation is that Zappos is owned by Amazon.com. I can guarantee that Zappos has some stout security in place, and yet one of the largest, most tech oriented companies on earth, just had a data loss of 24 million records. This tells me that that standards we have in place for protecting data, especially non-sensitive data, are not enough. We should not just be protecting financially sensitive data, but all customer data. Sure there may be no direct cost in replacing bank cards, or obtaining new bank account numbers, stopping checks, or posting chargebacks, but the effect to the customer when you lose their data can be remarkable. We&#8217;ve yet to see the actual damages that this breach causes, but with the sheer amount of information out there, there could be substantial damages.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1603/zappos-breach-all-is-well-no-credit-card-data-was-stolen/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>A Square payment without proper research fails</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1542/payment-technology-without-research</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1542/payment-technology-without-research#comments</comments>
		<pubDate>Thu, 10 Mar 2011 18:50:26 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Credit Card Equipment]]></category>
		<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Fraud]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantequip.com/merchant-account-blog/?p=1542</guid>
		<description><![CDATA[A long time ago I wrote an article about credit card skimming. It remains the most visited page on this blog, I believe, because credit card skimming is one of those concerns that apply to both consumers and to businesses. About a year ago one of the founders of Twitter and some other talented business [...]]]></description>
			<content:encoded><![CDATA[<p>A long time ago I wrote an article about <a href="http://www.merchantequip.com/merchant-account-blog/149/credit-card-skimming-and-places-that-sell-skimming-devices">credit card skimming</a>. It remains the most visited page on this blog, I believe, because credit card skimming is one of those concerns that apply to both consumers and to businesses.</p>
<p>About a year ago one of the founders of Twitter and some other talented business persons came up with a mobile payment method called square. Square is a very tiny card reader that attaches to the audio port on a smart phone. It&#8217;s truly a clever little device that utilizes an existing port that just about every phone has. Merchant&#8217;s can sign up with Square without any fee and just about instantly process. Because of the ease of setup, there&#8217;s been some angry customers with money held, but something like this should be expected as the services operates on a similar model to Paypal. Square got some quick funding, and went off to the races faster than any payment related service in history. However, there&#8217;s a problem&#8230;</p>
<p>Unfortunately, Square also introduced one of the most efficient and low cost methods of creating an advanced credit card skimmer. When you sign up with Square&#8217;s processing service, you get the square for FREE. That&#8217;s right, for free you can turn your iPhone into a credit card skimming device. Thieves don&#8217;t even have to pay the $50 or so for a skimmer anymore, they get one for free. Not only is Square efficient and free, but they&#8217;ve already distributed hundreds of thousands of these little skimming nightmares all over the US.</p>
<blockquote cite="Verifone"><p>A criminal signs up with Square, obtains the dongle for free and creates a fake Square app on his smartphone. Insert the dongle into the audio jack of a smartphone or iPad, and you’ve got a mobile skimming device that fits in your pocket and that can be used to illegally collect personal and financial data from the magnetic stripe of a payment card. It’s shockingly simple.</p></blockquote>
<p><strong>There are 2 major problem with the Square hardware. </strong></p>
<p>First, the square device does not encrypt data being transmitted between the reader and the phone. This could easily leave the service open to a targeted attack where other software could read the card information when it is being transmitted between the reader and the phone. This sort of issue may never be a major problem as it would take very specific software or a compromised phone for this flaw to be taken advantage of. However, it still remains a security possibility, one that cannot be overcome without updating the hardware completely.</p>
<p>Second, since the hardware has no encryption or secure link between it and the phone/square service, a programmer could easily write a program that would simply record the card information onto a database or file on the phone. This is the main problem that Verifone and many others are up in arms about. With the large memory cards that are commonly found in phones, a thief could theoretically store millions of card numbers on their phone. Additionally, since just about everyone has a cell phone, it is considerably less conspicuous for a thief to skim cards with a phone than with the dedicated skimmers which look something between a pager or a magnetic card reader you would see attached to a computer.</p>
<p>This morning, VeriFone launched <a href="http://www.sq-skim.com/">an entire website</a> dedicated towards bringing down square. While VeriFone is a direct and probably the largest competitor of Square with their PayWare Mobile App, they have quickly illustrated not only that the square can be used for skimming, but that there is software that can already be used with the square hardware.</p>
<p>The problem now is that there are tons of these square credit cards readers all over the place, so the damage has already been done. At this point there&#8217;s literally nothing that can be done to prevent skimming using square devices. There&#8217;s even applications for blackberry and android that already work with the square hardware even though it was designed for the iPhone and iPad. I think that this sort of hardware is a perfect example of what happens when a company pushes software or hardware without putting enough in the research in how to make it secure. There&#8217;s more than 1 way to steal a credit card number&#8230; </p>
<p>With the amount of focus on PCI and data security of the last 10 years this is a blatant disregard for the most basic best practices, even those established 10 years ago. Twitter may be a whimsical concept, but there&#8217;s really nothing amusing about completely botching credit card data security at the expense of consumers and the businesses whom accept those stolen cards&#8230;</p>
<p><strong>Update 03-10-2011</strong></p>
<p>So, Jack Dorsey <a href="http://techcrunch.com/2011/03/09/squares-jack-dorsey-verifones-security-hole-allegation-is-not-a-fair-or-accurate-claim/">issued a rebuttal to VeriFone</a>&#8216;s website and statements about the Square.</p>
<blockquote><p>Second, as Dorsey points out, credit card fraud is not new. Every single time you hand over your credit card to someone (whether it is a merchant using Square, or any one of the dozens of other credit card input methods) you are trusting them not to steal it. Criminals steal credit card numbers all the time, both online and offline. <strong>But it happens, and when it does, consumers are not liable for fraudulent charges, the credit card companies are.</strong></p></blockquote>
<p>What&#8217;s not fair or accurate is Jack Dorsey&#8217;s fundamental lack of understanding of how the credit card industry works! Any merchant knows that if they accept a credit card that was stolen, they are liable for the fraudulent charges. There&#8217;s no magical credit card company that&#8217;s going to float in and take responsibility for it. The merchant loses when it comes to credit card fraud, plain and simple.</p>
<p>This disregard to merchants  all while Square is trying to sell them a processing service is simply insulting. I&#8217;m a merchant as well, and this is just disrespectful.</p>
<p>After reading this, I am completely convinced that Jack Dorsey and Square have no business providing a payment service of any type to anyone. Stick to tweeting&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1542/payment-technology-without-research/feed</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>1 minute guide to PCI Compliance</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance#comments</comments>
		<pubDate>Thu, 15 Jul 2010 14:15:22 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1281</guid>
		<description><![CDATA[PCI-DSS has been around for several years now, and ignorance is less tolerated when it comes to data security. In case you are just learning about PCI, here&#8217;s the 1 minute breakdown on PCI compliance. PCI is a security framework created to help prevent/curb the loss of credit card data. It covers some of the [...]]]></description>
			<content:encoded><![CDATA[<p>PCI-DSS has been around for several years now, and ignorance is less tolerated when it comes to data security. In case you are just learning about PCI, here&#8217;s the 1 minute breakdown on PCI compliance.</p>
<ol>
<li>PCI is a security framework created to help prevent/curb the loss of credit card data. It covers some of the more basic  aspects of data   security, but is not security itself. <strong><br />
PCI compliance &ne; Security</strong>.</li>
<li>If <strong>you</strong> accept credit cards, you must be PCI compliant. No ifs, ands, or buts.</li>
<li>Most data breaches occur at small to medium size <strong>retail</strong> businesses. You  are a soft target and thieves know it! This is especially true if you  have a POS computer system.</li>
<li>Being PCI compliant does not remove liability in case you still suffer a data breach. It &#8220;may&#8221; reduce or eliminate fines but will not eliminate actual costs resulting from a data breach.</li>
<li>With respect to the actual process, gaining PCI compliance requires you to fill out a self assessment questionnaire (SAQ), and scan your networks periodically using an approved scanning vendor (ASV). Your exact requirements depend on <a href="http://www.mastercard.com/us/sdp/merchants/merchant_levels.html">which PCI level</a> your business is.</li>
<li>You can find a <a href="https://www.pcisecuritystandards.org/pdfs/asv_report.html">list of ASV&#8217;s here</a>. Most ASV&#8217;s can also assist in helping you fill out the correct SAQ.</li>
<li>If you are doing it yourself, you can <a href="https://www.pcisecuritystandards.org/saq/index.shtml">get the SAQ here</a>.</li>
<li>If you store credit card numbers electronically, you must fill out   SAQ &#8211; D. Have fun&#8230;</li>
<li>If you are PCI compliant, it does not mean that your networks and data are secure. Security is something that requires constant administration and vigilance, and requires far more than what PCI outlines.</li>
<li>If you don&#8217;t have the ability or expertise to be secure, hire or outsource to someone that does.</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1281/1-minute-guide-to-pci-compliance/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>VOIP + Credit Card Terminal = Bad Idea</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea#comments</comments>
		<pubDate>Mon, 07 Jun 2010 20:49:37 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1198</guid>
		<description><![CDATA[I&#8217;ve heard an alarming trend from a number of sources about how to hook up a credit card terminal to a VOIP (Voice Over Internet Protocol) telephone system. Several of the examples I&#8217;ve seen probably worked as well, so let&#8217;s get right to the point. Do not connect your dial-up credit card terminal to a [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve heard an alarming trend from a number of sources about how to hook up a credit card terminal to a VOIP <em>(Voice Over Internet Protocol)</em> telephone system. Several of the examples I&#8217;ve seen probably worked as well, so let&#8217;s get right to the point. </p>
<p><strong>Do not connect your dial-up credit card terminal to a VOIP connection!</strong></p>
<p>Even if you get this to properly work, which is apparently possible using an analog adapter, you are now violating a number of PCI regulations regarding data security. When you process using a dial-up connection, the data transmission <strong>is not encrypted</strong>. Since the transaction is going over a phone network which operates differently, with regards to security, than internet, it&#8217;s OK by PCI and issuer data security standards <em>(Whether the existing security is enough, is another debate)</em>. When you put that terminal on a VOIP connection, you are now transmitting unencrypted data directly over the internet.</p>
<blockquote><p>Encrypt transmission of cardholder data across open, public networks</p></blockquote>
<p>Do not do this, do not try to do this, and do not let your cable or other internet provider tell you that it&#8217;s safe and secure. I&#8217;ve heard of both Time Warner and ATT service reps telling customers that it is perfectly secure to do this. It&#8217;s not. Same thing goes for Magic Jack, Vonage, Packet 8, Comcast, or any other VOIP provider out there.</p>
<p>There is almost no way to encrypt data from your terminal over the internet unless your terminal supports end-to-end encryption, which realistically barely exists as of yet, or you have some extremely fancy and expensive telecom equipment. You would certainly know if you fall into this category.</p>
<p>If you have a VOIP only connection, you need to purchase an Ethernet compatible terminal, like a <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/verifone-vx-570/">Verifone VX570</a> or <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/verifone-vx-510/">VX510 (Dual Comm)</a>, <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/nurit-8400/">Nurit 8400</a> (Dual Comm) or a <a href="http://www.merchantequip.com/processing-equipment/credit-card-terminals/hypercom-t4220/">Hypercom T4220</a>. The T4220 and VX510 are the lowest cost out of this group. Get your new terminal programmed to connect over the internet by your processor. Connect your Ethernet terminal to a spare port on your Ethernet switch, hub or router.</p>
<p>Don&#8217;t try to get your dial-up terminal to work over VOIP even though it may be possible.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1198/voip-credit-card-terminal-bad-idea/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>PCI-DSS compliance becoming justifiable?</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable#comments</comments>
		<pubDate>Thu, 13 May 2010 17:49:47 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Industry News]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1115</guid>
		<description><![CDATA[Since I have became involved with PCI-DSS several years ago I have always had a major complaint about PCI-DSS. Merchants do not have protection from liabilities if they take the steps to become compliant! Now before QSA&#8217;s light their torches, let me just say that I completely understand and agree that PCI Compliance &#8800; Security. [...]]]></description>
			<content:encoded><![CDATA[<p>Since I have became involved with PCI-DSS several years ago I have always had a major complaint about PCI-DSS.</p>
<p><strong>Merchants do not have protection from liabilities if they take the steps to become compliant!</strong></p>
<p>Now before QSA&#8217;s light their torches, let me just say that I completely understand and agree that <strong>PCI Compliance &ne; Security</strong>. Nevertheless, from a business perspective it&#8217;s hard to take a program like this seriously when there is no real benefit from becoming compliant. One can always argue that security is a benefit, but in reality it&#8217;s not unless you actually prevent a data loss with it, and there&#8217;s no measurable monetary benefit of something that you don&#8217;t know was prevented.</p>
<p align="center"><img src="http://www.merchantequip.com/merchant-account-blog/wp-content/uploads/2010/05/pci-stamp.png" alt="" title="pci-stamp" width="420" height="344" class="alignnone size-full wp-image-1132" /></p>
<p>I do have a strong belief, which I think is further illustrated by the slow adoption rates of level 3 and level 4 merchants, that most merchants don&#8217;t take PCI seriously. Losing customer data is nothing to be joking about, but they way PCI has been implemented with liability dumped on merchants and processors, and the fact that compliant businesses get no protection over non-compliant ones, is laughable. Independent of the PCI Council which they helped start, MasterCard now requires security scans for all merchants even if they don&#8217;t process on the Internet or over an IP connection. How can PCI possibly be taken seriously if the founding companies create independent standards after they start an organization specifically to make sure they all have the same standards?</p>
<p><strong>So what&#8217;s the big news?</strong></p>
<p>Washington state <a href="http://www.storefrontbacktalk.com/securityfraud/washington-states-new-data-breach-law-says-assessor%E2%80%94not-visa%E2%80%94has-the-final-word/">just passed a law</a> (<a href="http://apps.leg.wa.gov/documents/billdocs/2009-10/Pdf/Bills/Session%20Law%202010/1149-S2.SL.pdf">HB 1149 <sup>pdf</sup></a>) that effectively legitimizes PCI, or at least legitimizes much of the cost in becoming compliant. What this law will do is grant a merchant safe harbor from liabilities resulting from a data breach, provided that the merchant was PCI compliant when the breach occurred. It also states that the breached organization&#8217;s compliance cannot be revoked as a result of a breach. Basically, if you were compliant at the time of the breach, you are still compliant after the breach. This sort of retroactive revocation of PCI compliance has occurred in several major breaches. From my observation, this law is the first breath of reason that I have seen pushed towards PCI compliance.</p>
<p>Business owners <em>(at least in Washington)</em> can look at PCI and assume, if we become secure and become PCI compliant, we&#8217;re no longer as-liable if some extraordinary circumstance results in us losing data. The proactive response is: let&#8217;s get this taken care of, lets make sure that our data is secure, and let&#8217;s get compliant!</p>
<p>Currently that same business owner is checking [YES] to all the boxes and emailing in their questionnaire. They&#8217;re asking, so it doesn&#8217;t matter if I&#8217;m PCI compliant, I&#8217;m still fully liable for any costs and damages if someone steals my data? Hmm&#8230; [YES] to all&#8230; DONE!</p>
<p><strong>The pitfalls</strong></p>
<p>With legislation like this there are pitfalls, and probably some big ones.</p>
<p>First off, the law states that merchants must be validated compliant within 1 year of the breach occurring. 1 year is far too long for a business that was compliant to be assumed to be still compliant. Additionally, this doesn&#8217;t address the fact that the business could quite easily take steps to actually become secure, but intentionally remove them for operations sake once they pass a security scan or self assessment.</p>
<p>Second, the law is only for Washington which makes it worthless in all practicality. However, the fact that one state is passing it may push Visa/MC/AMex/Disc to look at adding real protection to PCI.</p>
<p>Third, the law doesn&#8217;t address actual costs to consumers such as fees from bounced checks or other bank and credit associated fees. Merchant&#8217;s would most likely still be liable for many of these fees <em>(assuming that there are some)</em> if they suffered a breach.</p>
<p>Lastly, the law would justify costs for becoming compliant, but could put huge costs on someone else <em>(and it&#8217;s unclear who)</em>. If the merchant does suffer a sizable breach, it&#8217;s clear that there are real costs in re-issuing cards. What&#8217;s not clear is who would end up paying for them if this law is passed.</p>
<p><strong>Meaningless?</strong></p>
<p>Until this law is adopted by the issuers or put into effect on a national level, the benefits from it on a widespread scale, are going to be little to none. I&#8217;m openly against government regulation in any industry, yours or mine, so I do hope that card issuers and PCI security council take a serious look into adopting similar measures directly into PCI. I think that providing some sort of protection like this would greatly legitimize PCI especially in the minds of the business owners that are forced to become compliant and feel that PCI does not give them any benefit. It&#8217;s time for PCI to give small business owners a real reason to become secure and to become PCI compliant. A measure like this law is that reason!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1115/pci-dss-compliance-becoming-justifiable/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Blippy is why Visa and MasterCard should protect their merchants</title>
		<link>http://www.merchantequip.com/merchant-account-blog/1035/blippy-is-why-visa-and-mastercard-should-protect-their-merchants</link>
		<comments>http://www.merchantequip.com/merchant-account-blog/1035/blippy-is-why-visa-and-mastercard-should-protect-their-merchants#comments</comments>
		<pubDate>Mon, 26 Apr 2010 19:52:47 +0000</pubDate>
		<dc:creator>merchant account blog</dc:creator>
				<category><![CDATA[Data Security]]></category>
		<category><![CDATA[Fraud]]></category>
		<category><![CDATA[Industry News]]></category>
		<category><![CDATA[Merchant Accounts]]></category>

		<guid isPermaLink="false">http://www.merchantaccountblog.com/?p=1035</guid>
		<description><![CDATA[This last week, a social networking company Blippy, notified the world that at some point they suffered a small data breach involving a handful of their customer&#8217;s credit card numbers. Blippy is a service that allows people to share and discus, the purchases that they are making in near real-time. Basically, every time a Blippy [...]]]></description>
			<content:encoded><![CDATA[<p>This last week, a social networking company <a href="http://blippy.com/">Blippy</a>, notified the world that at some point they <a href="http://mashable.com/2010/04/23/blippy-credit-card-numbers/">suffered a small data breach involving a handful of their customer&#8217;s credit card numbers</a>.</p>
<p>Blippy is a service that allows people to share and discus, the purchases that they are making in near real-time. Basically, every time a Blippy user makes a purchase using their credit card, it shows up on Blippy. A little bit like twitter, a user can also embed their blippy feed on their blog, facebook profile, other social network, or website, and their followers can track and discuss every purchase that they make. For this to work smoothly, Blippy obviously needs to store and access some very sensitive information.</p>
<p>This data breach looks like it was extremely small, completely insignificant for realistic purposes, but I think it brings up some very strong points that should question card issuers stance on protecting their card holders.</p>
<p>The reason that Visa and MasterCard should provide some sort of protection <strong>for merchants</strong>, is that if card holders are stupid enough to share their credit card and bank login information with a social networking site such as Blippy, there&#8217;s really no reason that they should be continue to be protected at the expense of merchants. It&#8217;s simply absurd to think that merchants should bear the cost of people so ignorant that they would give their banking information out to some random website. &#8220;Social networking&#8221; and &#8220;security&#8221; are 2 terms as synonymous as fire and water.</p>
<p>One could always argue that Blippy should have kept the information more secure, which is obvious, but the real problem here is that credit cards are not meant to be used in this manner. It&#8217;s just baffling to me that someone would actually enter their card or bank login into any site that they do not have a close relationship with, or are making a purchase from. Then to expect their bank to cover them from unauthorized charges, is just beyond any reason. It&#8217;s reckless on Blippy&#8217;s part to make a service based on and requiring such sensitive information, and it&#8217;s even more reckless for card holders to share this information.</p>
<p>A quick example of the absurdity of this service is a line in Blippy&#8217;s terms of service:</p>
<blockquote><p><strong>Privacy:</strong> You may not publish or post other  people&#8217;s private and confidential information, such as credit card  numbers, street address or Social Security/National Identity numbers,  without their express authorization and permission.</p></blockquote>
<p>Hey, but Blippy can publish yours&#8230;</p>
<p>To me, this service is clearly crossing the line where credit cards were not mean to and should not go until major modifications to security and merchant protection are established!</p>
<p><strong>To top it all off, Blippy issued this <a href="http://blog.blippy.com/2010/04/23/blippy-and-credit-card-numbers/">statement on their blog</a>:</strong></p>
<blockquote><p>In general, it’s important to remember that you’re never responsible if  someone uses your credit card without your permission.</p></blockquote>
<p>As a merchant and a merchant service provider, I don&#8217;t want to end up taking a stolen card because a card holder decided to hand out their banking information to a social networking site, who thinks that chargeback expenses are somehow covered by a magical chargeback fairy. It&#8217;s the merchant that accepted the card who eats the cost of your poor programming, and complete lack of data security. I think Visa and MasterCard need to step in right now and quash this type of service, and specifically Blippy. It&#8217;s really simple, as Blippy is not involved in any part of a credit card transaction, they have no right to a card holder&#8217;s transaction information.</p>
<p>Blippy has <a href="http://blog.blippy.com/2010/04/26/blippy-issues-resolutions-plan/">issued resolutions</a> to prevent this from happening again, but realistically their service should be canned now! My hat goes out to anyone who can get a $12M investment in a service that lets people share their purchases with the world, but it&#8217;s time that this is stopped before it gets out of hand.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.merchantequip.com/merchant-account-blog/1035/blippy-is-why-visa-and-mastercard-should-protect-their-merchants/feed</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
	</channel>
</rss>

