As you said, you'd probably put him out of business, and regardless if that's your competitor or not, it's still a human being with a life that will be ruined.

As icebraining mentioned earlier, it's not illegal to not be in PCI compliance, just really, really dumb.

His reply would be key to determining which is true. If he purposefully did it to save costs, not caring, etc. then you have good reason to publicly call him out on it. If he truly was clueless and this is a big oh shit moment to him then you have a couple options you didn't otherwise have. If he doesn't have a big dev team (and if he does they seem incompetent) he might be willing to sell instead of spend the money to fix everything. There might also be some other creative solutions that would be beneficial for you rather than attacking it head on publicly.

And in any case, would a report really be likely to put him out of businesses for just this mistake? That doesn't seem in the interest of the people doing the analysis.

Whistleblowing often has negative consequences for the whistleblower.

It is laudable to Do The Right Thing(TM), but the personal cost is likely nonzero sum.

Be aware, tread carefully, CYA.

- first let them know you know, and that you'd like for this to be handled in the best interest of the users (that's who you're doing this for, right?)

- then, depending on the response you have several options:

- If they stonewall, alert the public

- If they respond, figure out what a reasonable timeframe should be for them to become compliant

- Then give them that much time and review the new situation

- If they're still not compliant but have made progress review the situation from the new vantage point

- If they have not made meaningful progress, alert the public.

Don't let this 'opportunity' get the better of you in the ethics department, what goes around comes around and since you're doing your utmost to be anonymous here be aware that you too might have a skeleton or two in your closet and making enemies with nothing to lose might not be in your advantage.

On the other hand: building a bridge for a competitor to walk over when they were vulnerable might place you well some years down the line when that founder is looking for succession.

As for the whole PCI compliance thing: depending on where this all happens in the chain the company might be lying about them being PCI compliant or their auditors have messed up, either way nobody appointed you judge, jury and executioner so tread with some care, the whole thing might backfire in some unexpected and spectacular way if it turns out you were mistaken.

I'd report it and be done with it. Minimal drama and involvement. Alert the public as a very last resort, if the PCI folks are uninterested (and I guarantee you, they will be interested).

This gets worse when bank accounts are involved because the protections for businesses and consumers are next to nothing if your information is leaked out from a legal perspective and there are many instances of banks not backing up their customers.

We ended up ending a consulting engagement because a client had some big holes in their account security for bank accounts and had no interest in rectifying that. Our problem with that was twofold. First, the customers our former clients had no idea that there was an issue and second, if a breach did occur it could have put our clients customers out of business. There are stories about that happening.

I have personally run across way too many business that are interested in making money, even if that is at the expense of others with severe consequences for those actions.

My $0.02: maybe this is just one way your competitor is inept at running their business. I'd say the probability is very high of that. An overwhelmed founder IMO may be a sweet acquisition target. If he knows he is in over his head, maybe he would be happy to sell you his company for terms you can accept. You'll get all the customers, and you'll also know those customers are in your good care.

If you whack him upside the head with a report to Visa, MC, etc. he'll fix it and continue to be ignorant or negligent in all the other ways he is failing to adequately serve his customer base.

Lastly, and please know I am not accusing you of a nefarious plot here. But anyone reading this will see the potential prize of acquiring a competitor's client base. I want to dispel the myth that a report would be a fatal blow to his company that would result in your company ending up with all his customers. His merchant bank who is really on the hook for his PCI compliance will not terminate his account over a first offense. They will instead make even more money off him by imposing remediation consulting. And if those expenses were to put him out of business, there would still be an acquisition cost in reaching his customers, letting them know that your company exists and selling them on your solution.

My general approach to life: I do my best to limit my actions to those that will enhance or maintain the quality of my reflection in the mirror.

Meta: http://inewsdesign.com/2012/11/21/richard-bransons-tip-why-y...

You should report him for the same reason that you should report a competitor that is dumping toxic waste in a stream.

They are externalizing costs to society as a whole to maximize their gain.

There is no malice is demanding that everyone respect the law that safeguards us all.

If the competitor does not wish to follow the law then they can move to a locale that does not have that law.

I agree OP should report them, though.

Unless a law is being broken AND it's creating an unsafe situation for your customers or your company, leave it alone. In my opinion it's a classless move to go after your competitors in that fashion. Beat them with a better product. In this case, a "better" product would seem to be one with PCI compliance.

As far as the "toxic waste" analogy -- I've never heard of anyone getting cancer and dying from a lack of PCI compliance. In fact, there are likely more important things to worry about than PCI compliance -- Target and all of the other high profile retailers that were credit-card hacked -- they were all allegedly PCI compliant, yet it still didn't do much good. I'm not hear to debate the value of PCI compliance -- if it's a requirement of your business, then obviously you have to do it. But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.

How do you conclude that it didn't do much good? The Target breach involved installing malware on the point-of-sale terminals to grab the data as the customer was paying.

As far as I know, the attackers didn't get to the stored credit card data. I suspect that they didn't get to that data in large part because Target was mostly in PCI compliance, meaning that the stored data was encrypted, on database servers isolated from the databases not involved in payment processing, on separate networks with strong access restrictions.

If Target had been treating PCI the way OP's competitor is, the Target breach could have been much much much worse.

> But I am debating the ethics of reporting a competitor for an activity that is NOT illegal, nor is it directly harming your customers or your business.

For a small business that is doing its own credit card storage, PCI compliance costs can be significant. They can easily double or triple the number of boxes you need at the data center.

The competitor is saving a lot of money by completely ignoring credit card security, which gives him an unfair advantage over OP. I'd consider that sufficient harm to OP to justify taking action.

That happens a lot and there are ways to deal with it, ratting out your competitors to authorities with silent hopes of crippling them and taking their business in the name of protecting the consumer is bad form at best and will come back to bite you hard at worst.

The person I was responding to was taking the position that you should not take against against someone if they are not harming you. That money saving, regardless of how it came about, harms OP's business, and so justifies action.

Note I didn't say the action should be calling authorities. Contacting the competitor and letting him know there is a problem would be action, too.

It wasn't about cost cutting. It was about me being young and foolish (and, looking back, I'm not sure it's even the stupidest mistake I've deployed to production in my career, but I'm not sure I want to admit to the other candidates just now :).

Also: if you want to delve into counterfactuals, consider what most PCI-compliant encrypted card storage schemes look like. Design a straw-man system yourself. You'll see the problem within minutes of starting. Remember that any cryptographic engineering that requires even a minute's worth of 'tzs cleverness is probably utterly beyond the raw capability of a line-of-business programmer at a major retail chain.

To the parent commenter's point, it's worth making a list of the 5 largest credit card breaches of the last 5 years and noting who provided their PCI attestation; you may find the result interesting.

For instance, suppose you allow orders over the telephone. A customer can call, talk to a salesperson, and then place an order. The customer will read their credit card information over the phone and the salesperson will enter it into the ordering system.

If your phone system is a VOIP system, congratulations! It's in scope for PCI! Since you probably don't want to have to deal with PCI for every phone in the company, you'll probably end up having to segment your system, so you can restrict sales calls to one segment.

If you are recording some sales calls so that managers can review them for training purposes, you either have to find a way to not record the parts of calls where credit card numbers are read, or you have to treat the recording as sensitive cardholder data and encrypt it. You might think you could just encrypt all the recordings and be done with it. Sadly, that's not good enough, because of the CSC code. You are not allowed to store the CSC code even if you do encrypt it.

Some people implement a system whereby the salesperson can press a button when the customer is about the give sensitive information, and that pauses recording for a few seconds. From what I've read, this is NOT sufficient for PCI compliance.

There are some approaches (aside from giving up on recording) that appear to be acceptable.

1. There is a system called CallGuard [1]. You integrate this with your phone system and your order entry system. When it is time for the caller to enter their card number and CSC, they do so with their phone keypad instead of by voice. CallGuard blocks the touch tones from the recording, interprets them, and enters them into your order system.

2. You can make it so that when a salesperson brings up the card number and CSC entry form, that automatically pauses recording until the form is submitted.

3. You can temporarily transfer the call to an interactive voice response system that gets the numbers and puts them in your order form, and then transfers the customer back to you.

Next up--email! A customer's recurring payment fails because they did not update their account when they got a new card. Your system sends them an email. The customer wants to update their card in response. Some will try to do this by email. They will fire of an email to your support address that tells you they have a new card and includes the number.

Now you've got a credit card number stored in the mailboxes of everyone who receives copies of support requests, and you'll have to do something about this. At least with a credit card in a mailbox, it's likely to be in a fairly standard and documented format.

If your company is big enough to have outgrown handling support requests by having a "support" mailbox that all your support people read, you probably have some kind of help desk system, and that's where that customer email with the credit card number ends up. So now you find yourself digging around in some big PHP codebase, and poking around a MySQL database that has a couple hundred tables whose names make no sense to you, trying to figure out how tickets are stored and what you have to do to modify a ticket to mask the credit card.

And somewhere in here, you should be thinking about how you will write a script to scan for these things, so you don't have to rely on support people noticing them and calling them to your intention. You'll have fun discovering the various ways people can vary the formatting of credit card numbers. When you make your credit card number recognizer handle enough weird formatting to work well, then you'll find someone that gave you a zip code (5 digits), and a phone number including the '1' for long distance, and formatted those so weirdly that your credit card recognizer flagged them.

...and let's not forget about chat. If you do support via chat, you will have people typing in credit card numbers. If you are lucky, your chat system is part of your help desk system, and so while you were reverse engineering that to deal with credit card numbers in ticket, you happened to figure out where and how it stores chat logs.

If you do NOT automate dealing with email and chat, at some point a support person is going to bring to your attention a ticket or chat log with a credit card number, and you'll go into the database and fix it. If you are lucky, the support people noticed it quickly. If you are unlucky, it was sitting there for a while--and so it is now on your backups.

[1] http://www.callguard.co

This is not true. As a vendor, I assume costs associated with PCI compliance and other industry-standard best practices. If my competitor is ignoring these I am fundamentally disadvantaged. It's not an equal marketplace at that point.

Whether intentional on the competitor's part or not, this is saving them money and placing their customers at risk of identity theft, financial fraud and who knows what else depending on what's stored in that database.

> But reporting him to the authorities? That's very Stasi-esque.

Holy hyperbole, Batman. As a customer, I deserve to know if my vendor is eschewing industry-standard security practices. And they should be mercilessly shamed if they are.

Actually, no. If the CC numbers are used fraudulently, the clients of that company will just issue chargebacks; at most, they'll need to get new cards. The people who'll have to pay are the merchants who will get hit with those chargebacks - and indirectly everyone else, since prices are raised to pay for those losses.

Are you advocating that unless you're black, you shouldn't have supported (or got involved with) the black civil rights movement?

Edit:: I have not made up my mind yet. Admittedly, at the time of posting I was leaning more toward that side.

After reading everyone's advice, I'm leaning more toward a multi-tiered approach as @jacquesm suggested. It seems to avoid bad karma and burning bridges. Also, it seems as though the PCI Industry rarely acts on reports. So, working with the competitor to fix their issues could be the best thing down the road. It's a very small industry, and the possibility of a buy-out could exist in a few years.

Similarly, I find it to be insanely frustrating when people ask for advice, but are not willing to listen when they get it. It feels dishonest.

(b) It seems to me that the customer in question is in a much better position to file a complaint than you are. I can't see anything wrong (but see (a)) with writing them a detailed letter explaining the implications of what you found during the transfer. They will probably not want to act on it, but if they do, they can't be accused of ulterior motives.

(c) You could try the tack of advertising very loudly that you're PCI compliant, without ever mentioning your competitor. (Is there third-party PCI certification? If so, you might want to get it.) Yes, everyone who handles credit cards is supposed to be PCI compliant, but customers don't necessarily know that; you could perhaps make it a differentiator. If your competitor is so unscrupulous as to advertise themselves as compliant when they're not, possibly (see (a)) you could then report them yourself.

For it to actually really hurt your competitor, you'd have to probably astroturf some forums, acting like concerned customers, and get other customers upset. And even then, you're just going to cost them a week or so. Maybe if you timed it for maximum damage, but just don't waste too much time on it.

Regardless, I still feel reporting is the ethical thing to do.

2. TORTIOUS INTERFERENCE COUNTERCLAIM: The competitor's terms of service with the customer probably include restrictions on access to the competitor's system. The competitor thus might claim that the OP's accessing of the customer's data constituted "tortious interference" with the competitor-customer contract. [3] The competitor's lawyers are likely to pursue such a claim, because it lets them reframe the issue in their favor, it might allow them greater discovery from the OP, and it could also lead to a punitive-damages award. (Whether a tortious-interference claim would succeed depends on a lot of facts that we don't have.)

3. CFAA VIOLATION: As others have pointed out, depending on the circumstances, the OP might have violated the Computer Fraud and Abuse Act. [4]

All of the above assumes U.S. law applies.

[1] http://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=...

[2] U-Haul v. Jartran, 793 F. 2d 1034, 1041 (9th Cir. 1986) http://scholar.google.com/scholar_case?case=1381884152605222...

[3] https://en.wikipedia.org/wiki/Tortious_interference

[4] https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

It is unlikely that reporting it to said merchant processor will result in account termination since if your competitor is not at the level where an audit is required, he/she is simply filling out a form.

Incidentally, PCI-DSS 3.0 went into effect today, so anyone using Heroku for commerce became non-compliant today!

https://www.google.com/#safe=off&q=add%20to%20cart%20site%3A...

This is the issue. Chances are Heroku has a very secure infrastructure, but the world will never know unless it allows various audits to be generated for compliance purposes.

> There's a caveat, however: if your payment platform is completely segregated from your Heroku environment, you might be good to go

Not true, see below:

https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...

Exactly. And, personally, I think this is rather odd. They could solve this in a heartbeat.

>Not true, see below:

Duly noted and thanks for the link, but here's the thing, though: what if you're not eligible for a self-assessment?

If you're doing higher transaction volume and are not eligible for a self-assessment, you have to have a certified QSA sign off on an audit of the internal processes.

The QSA will make sure that all the required systems and processes are in place and sign off on it.

PCI is definitely a fairly frustrating thing to deal with but there are some good practices underlying it that many orgs would simply not do if it weren't required by their merchant processor.

Can you elaborate a bit on that? Thank you.

https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.p...

http://blog.spreedly.com/2014/03/26/saq-a-ep-a-big-shakeup-f...

If you want to use a PAAS and want to be able to pass any kind of infrastructure audit, the fastest path is probably via Aptible (YC S14)

With that in mind, this discussion only applies (right now) to sites who have never yet filled out a PCI form. For sites which have, it only applies when their annual re-certification comes up.

So for those sites which have to certify against 3.0, can they run on a PAAS and take payments? It depends, specifically on how the credit card number is entered. The general rule of thumb is that if the form in which the number is entered is delivered by the host (the PAAS), you'll have to use SAQ A-EP (which is extensive, and you don't want). if the form is delivered by the vendor (like Stripe) and injected into the page, you can still use SAQ A (which is small, and what you want).

How about Stripe? I'm not sure if they've released a PCI 3.0 version of Stripe.js yet, although they clearly will. Likewise, I'm not sure about the others, but I think it's safe to assume that they'll release versions similarly (the techniques to do this are well-known).

Lastly, I'm not a QSA, and this isn't advice.

The entire point of SAQ A-EP is to cover the edge case that was letting people use offsite, iframe, and js checkouts. It puts the web server that is doing the hosting of the site in general into PCI scope.

So essentially, every card payment service where the merchant's web site touches the payment flow beyond directly linking to an entire page hosted by a third party is dead? Because on a literal reading, I don't see how any of those services or the merchants using them can possibly be exempt from the new rules, and I don't see how it is going to be commercially viable for any small merchant using any of those services to comply. Say goodbye to Stripe and its various clones, Checkout or otherwise. Forget using any sort of A/B testing on your sign-up pages that isn't entirely self-hosted, or using any third party analytics to track visitors through the flow. Basically, you can use a fully hosted service provided by a major bank (and we all know how well those convert and how well the giant financial services firms typically treat small businesses) or you're out of luck.

If that is really what the new rules are meant to say then this appears to be dumb on an EU VAT mess scale of dumb, with the added dumbness that since it's not actually a legal requirement to comply with PCI DSS, roughly 0% of merchants who should in theory be affected actually will. All it's going to do is reinforce the image of the card payment industry as a dinosaur and hasten its demise by destroying the best idea they've had in years: allowing small businesses to actually take card payments on-line without jumping through silly numbers of hoops.

No, including payment pages hosted by a third party:

https://www.pcicomplianceguide.org/new-saq-a-ep-hones-in-on-...

The important thing to note is that it would not be very difficult for Heroku to allow websites to gain compliance. One should be able to type:

  $ heroku document:network 

The other half would easily be covered by publishing general policy documents about data center policies, etc., similar to what Amazon already publishes. Heroku can simply reference all the existing AWS service provider documentation and then add a few of its own documents covering the stuff it manages (things like password control policies, etc.) Also it would be helpful to allow the admin panel to require multi-factor auth.

So it's not really all that absurd. For all we know Heroku has a few massively glaring security holes and as we type people are skimming lots of payment information...

PCI is not a legal requirement, simply a moderate quality list of best practices. That Heroku and other PAAS vendors have trouble doing this should probably be cause for some actual concern.

As far as I can see, the only significant attack that this addresses is someone compromising your site and changing it to redirect to a malicious alternative instead of your real payment service. But since any fool can set up a site that looks the same, has a similar domain name, ranks about the same in Google, but is entirely fictitious and exists only to harvest cardholder data, and moreover following that strategy would be far easier than compromising a legitimate merchant's site in many cases, this is a poor attempt to mitigate a threat that is in practice impossible to avoid.

If this is really all true then I'm pretty sure PCI DSS just became irrelevant to most small on-line businesses. There's no commercially reasonable way for them to comply with those terms. There's no legal threat if they don't (at least not in most places; YMMV) so we're purely talking about financial liability here. And from a financial point of view, you might as well just accept that if you get a breach and card data leaks then your business will go bankrupt paying the fines whatever you do, so you can ignore the whole thing anyway. The only other meaningful sanction the card services have is refusing to allow the same company representatives to take card payments at other companies in the future, but if they would do that for this reason then probably you were never going to work with them again anyway.

Stripe and similar services are themselves PCI compliant and have extensive documentation, audits, etc.

Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.

PAAS vendors are one of the most likely attack vectors which is why they are in scope with SAQ A-EP.

If you are seriously under the impression that you could easily set up silhouettesfakeamazon.com and start harvesting credit cards, I challenge you to try it :)

Otherwise, the merchant still appears to come into scope, because at some point they must redirect their customer to the externally hosted payment pages or load the externally hosted checkout system from the merchant's site, one way or another.

So basically, it looks like anyone who has any sort of shopping site they run themselves (as opposed to hosting entirely on a third party marketplace site) but who uses Stripe, PayPal, a hosted card payment page offered by their bank, or literally any other third party card payment system, will fall into scope and be required to operate and audit the entire relevant part of their web site according to the PCI DSS 3 rules. But that is obviously far beyond the reasonable capabilities of most merchants who might find themselves in that position, either technically or commercially.

Edit: In short, when you wrote:

Sites remotely hosting js are definitely an attack vector that PCI hasn't yet decided to put in scope.

I haven't yet found anything that says why such a site doesn't fall into scope now just like everyone else. Indeed, the new rules seem to be clearly aimed at such sites as I read them.

The issue is that Heroku, because of its lack of transparency about what is actually going on in its routing mesh, is not necessarily secure, and it's not possible to just download a list of relevant firewall rules, etc. (the way you could if you set up a site on Amazon VPC).

SAQ A has always required the merchant using his/her own servers to provide some documentation and do some security scanning, the new thing with SAQ A-EP is that it no longer allows for the loophole of using a PAAS and claiming that simply b/c it is not managed by the e-commerce shop that it is out of scope.

I think you are dramatically underestimating how many very small businesses, private individuals, bootstrapped start-ups, etc. would be caught by this.

For one perspective, consider that in the current EU VAT mess, some estimates have suggested that over 250,000 microbusinesses are selling on-line in the UK alone right now (or at least were until the end of last year). Many of them are side businesses, either earning a little bit of extra money for selling anything from music to knitting patterns, or second businesses run by folks who already have full-time jobs. Of course some of them are entirely built on marketplace sites, but plenty aren't, they just know enough web design to set up a basic site and slap something like a PayPal or Stripe Checkout button on the page.

To a first approximation, none of those businesses is going to comply with the new rules, despite operating their own site and taking money on-line via credit card. They wouldn't even know what the long words meant. Even the outliers who do, either because they're in an IT field or maybe if they're a bit larger and have slightly more resources, probably don't have the time and money available to comply.

These are ma and pa shops, family businesses, side businesses run in people's spare time, start-ups trying to gain traction, and so on. They don't have their own networking team. They don't even have a dedicated IT guy. And they surely can't afford to double the number of servers they use just to avoid the redirect issue, to pay specialist consultants to figure out all the details of their almost certainly outsourced IT infrastructure, whether or not the infrastructure provider makes available the necessary data in some form, and to spend hours if not days figuring out how to self-certify under the new PCI-DSS rules.

Avoiding that kind of nonsense is, after all, why these organisations use services like PayPal or Stripe or the hosted pages from their bank in the first place.

> I think you are dramatically underestimating how many very small businesses, private individuals, bootstrapped start-ups, etc. would be caught by this.

This is not new, it has been part of SAQ A for quite some time.

Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?

This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0

There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A.

Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A.

Per the linked doc: What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process.

SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.

As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding...:

Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')

SAQ A applies when using one's own server infrastructure, and SAQ A-EP applies when using a PAAS.

Edit: The new questionnaires went into effect today. The previous year's were still applicable through last year.

Or is this some small operation which provides services for a niche market and is below the 300,000 transactions/year where it gets serious? Then, maybe not so much.

Visa is quite serious about enforcing those standards. They took away every user-facing credit card reader from Barnes and Noble for a year after a breach. They took away Sony Online's ability to accept credit cards at all for several weeks after Sony had a breach.

Huh? As a service provider who has to deal with these third parties (for our hosted/colo type of clients) I would say I have yet to find one that isn't corrupt.

They basically are completely worthless, at least at the lower-tiers. They more or less run nmap and a nessus scan, and then tell the client how to game those scans without improving security whatsoever (e.g. hiding an exploitable version of PHP's version banner, firewalling the test probe IPs from certain ports the world can see, etc.).

In fact, from a service provider perspective PCI has made things less secure since we no longer have as much traction with clients when we tell them they need to do X to store financial data securely. Now they can point to their "audit" and say it's fine.

> Visa is quite serious about enforcing those standards.

Not in my experience. They only seem to care after a breach happens and only for PR purposes. Report anything before that, and from what I can tell it's completely ignored.

That said, we generally don't deal with the higher compliance levels - those that do, seem to get it more or less right (or at least put resources and thought into it if nothing else).

Believe me, if your competitor saw you doing this stuff they would definitely report you. Kill or be killed. You think Marc Cuban or Donald Trump is worried about their users when they have an opportunity to take advantage of a competitor?

Second, it's not kill or be killed, if that was all there was to it then why not hire some Russian goon squad to bring down your competitors web-site? After all, they could do the same to you... Most likely the idea that all of the competitors business would be taken over and that they'd go spectacularly bust is a pipe dream at best.

And let's let Marc Cuban speak for himself (as far as I know he's not going to stoop so low as to intentionally damage a competitor for his own advantage), for Donald Trump I'll hold up the inconclusive data flag.

If you run your business the way you do then it will definitely reflect back on you in most cases, you'll find that one day the tables are going to be turned and then you'll be all out of sympathy.

Sure, business is ruthless. But it does not automatically mean that you can back-stab your competitors for your own glorification. And if it does then I'd rather not be part of your circle, toxic attitudes create toxic environments.

If you think that the only way you can grow your company is at someone else's expense then maybe it's time you spent a few $ on marketing instead? Very rare to find an ocean empty of fish.

I don't know how you found these violations and, for all I know, you may not even be in the United States, but if you are, I would consider speaking with an attorney (preferably one with experience working cybercrime cases) to make sure that you aren't going to stumble into CFAA territory.

If I were your competitor, if I happened to find out that it was you, one option would be to call, "HACKER!! EVIL HACKER!!" And, looking at some recent cybercrime prosecutions (ie - aaronsw), if your competitor happened to catch the ear of the right prosecutor, you could be in heaps of trouble.

I hope that you do report this - your competitor honestly sounds like a scumbag. But, because he/she sounds like such a scumbag, they may not fade gracefully into obscurity. Protect yourself accordingly.

Yes it will benefit you, but more importantly it benefits his customers because it gives them additional facts they did not have before about the trustworthiness of the vendor they're using.

The fact that you are a competitor with this malicious actor should have no bearing on your decision.

I think more people need to understand that security is important, implementing the security precautions that you're aware of isn't enough anymore. You need to be active in the community to make sure you're up to speed on recent developments, and that you're following Best Practices where possible. Anything less is insufficient.

It's us the customers who are hurt the most when company databases get hacked. Companies should start showing some respect for that fact by taking security seriously.

If you want to damage their reputation, write a blog post in a way not traceable to your company exposing the actions of your competitor. Or get a news agency to notice, and be an anonymous source. This probably isn't worth the trouble.

The white hat solution, as others have mentioned, is tell them. If they don't have the problems resolved within some reasonable time span (a month if you're feeling mean, 6 months if you're feeling nice), then I would say you're morally justified in smearing the hell out of them.

This will also bring to light anyone complicit in the violations as well (e.g., companies contracted for performing audits, who aren't taking due diligence), so the benefit to everyone is more than just having your competitor clean up his act.

Note that this doesn't always impress customers – and sometimes mentioning security concerns activates customer paranoia such that they convert at lower rates! So you may need to test this.

But, if your customers are security conscious, they'll notice the differences when comparing offerings. When they ask your competitor for details, the competitor will either offer false reassurances, or become increasingly aware of their deficiencies, and fix them. (And them fixing their issues may be in your best interest: a famous failure by your competitor could stain your whole category as too-risky for wider adoption by your target customers.)

If and when there is a damaging breach at any competitor, your practices (and marketing) going back to before the breach can help immunize you somewhat from the fallout, even without you ever directly naming the competitor or its failings. (To directly mention a competitor, or its specific troubles after an incident, could be seen as classless and easily backfire. Not only may you have a lapse yourself someday, but any 'gloating' may draw retaliation from competitors or extra attention from criminal hackers who get more glory when compromising systems that brag about their security.)

I have a customer who told me that her manager's boyfriend was writing down customer's addresses to go rob them. The nature of the business indicates that the customer is not at their home for extended periods of time. We ended up building in user permissions to see name, address and phone number.

This raises an interesting hypothetical.

Let's suppose that there was no PCI violation, or any other ethical or legal problem with his business, but that through better pricing, service, more effective advertising, or something like that, you found yourself taking away business from him to the point that he might be driven out of business.

Question: would you put limits on your growth, or cut back on your advertising, or raise prices, or take some other steps to keep him in business?

If you report him, you're going to have to explain how you discovered everything you've outlined without exceeding the intended access to the system.

I see a lot of downside here for involving law enforcement. You run the risk of being accused of hacking your competitor.

If I was in your shoes, I probably wouldn't report him, but I probably wouldn't be quiet about the weaknesses of your competitor's security.

I agree with the sentiment of "reach our to your competitor privately, inform them of the problem, and suggest they fix it". They may be your competitor, but they probably aren't Satan incarnate, and they'll probably be grateful, and building that relationship may actually be beneficial down the road.

Look at the history with Peter Thiel and Elon Musk before they merged their respective companies. They were competitors, yes. But if either had chosen to make things personal and go into full on attack mode, they might never have merged, we would not have gotten Paypal, and Peter and Elon probably wouldn't be billionaires now. To be fair, you can argue whether or not it's a Good Thing that we have Paypal, but from their subjective perspective, it was better that they were on good enough terms to have the merger conversation.

Reporting someone is a pretty weak move. A strong move would be a campaign emphasizing the superior features of your product, such as PCI compliance. Seems like a pretty easy sell, especially in today's environment when there's a security breach every five minutes.

As far as putting them out of business, I wouldn't be so certain of that outcome. For one thing the matter of PCI compliance is between your competitor and their payment processors. If you figure out a way to report them, their processor may just give them a chance to fix it and it will all be handled quietly. Or it could result in an audit, fines, their processor dropping them, etc. Those are all bad for the competitor, but not necessarily something that will put them out of business.

Posting on a public forum has potential to scare customers if there is such a place to post your message for your niche where "everybody" will see it. But there's a lot of ways for that to backfire as well depending on how you handle the posting of the message.

If you don't, you're exposing yourself to many problems for very little upside, and my experience is that, when cornered, most people don't tend to react in a reasonable and logical manner (or even in a manner that caters to their own interests). For example, the competitor could accuse you to have came across this information illegally (whether you did or not in the eyes of the law is irrelevant: once you're faced with a lawsuit, your best likely outcome is that you will only have to pay your lawyer's bills); or, they could think you're preemptively covering your ass before starting a smear campaign against them, and beat you to the punch with accusations and threats of their own, and so on.

On the other hand, as some have pointed out, this is a good marketing opportunity for you—you just need to be careful how you use the information. I would, however, avoid making _any_ references to competitors (even indirectly by referring to “our competitors”), because you don't want to be petty, and you also don't want to ever have to answer the question “Who are these competitors of yours?” in front of a court stenographer.

You do not mention if the PCI violations could flow through to your competitor's clients; are the credit cards those that customers use to pay for the competitor's SaaS, or are they stored on behalf of customers to provide the service itself (e.g.: the way, say, Stripe stores your customers card data for you)? A breach that leaks credit card data in this case would be catastrophic not just for you, but for your customers as well—and these are consequences that have a material impact on the quality of your product over your competitors'.

From a marketing viewpoint, keep in mind that the value this piece of intel is also likely to be proportional to the sophistication of a prospective customer. A potential large client that could is more likely to be sensitive to something like PCI than small fish, and knowing that you can plant the bug in their ear that your competitors might not be as up-to-date on PCI as you are could make the difference between a sale and a missed opportunity.

Tell them and let them know you're prudently reporting it for your own sake.

If anything, perform due diligence and get in touch with someone with the appropriate levels of scruples and power to take action.

Who knows? They may find out something worse about your business and respond in kind, instead of dragging your company through the mud publicly.

(unofficial site) http://www.pcistandard.com/card-association-fines/

Sure, if you anonymously tell them about the security loophole, will this fix future problems?

Likely not.

I say report them.

There's nothing wrong with reporting bad behavior. You're not responsible for the consequences they have to face for making those decisions.

Google, Microsoft, IBM, Apple, ... wouldn't even think twice.

If you want to use this as a selling point when engaging his current customers, I see nothing wrong with that. If you offer greater security than he does, it's fine to point that out.

You could also get your sales team to call your competitor's current customers and ask "How safe is your data with "X"? Are you looking for a super-secure alternative? Buy my product." Or something...

Typically any PCI certified installation that does not self-certify will have something come up in their annual review. That doesn't mean they immediately lose their certification, it means they get 'x' days to fix the the item and then they are no longer in compliance.

That's when they might get fined but if a breach occurs the fines are pretty much a given.

Fines are extra income for VISA, they typically have no clear relationship to the infraction other than that it is what VISA thinks they can bear or how much they can get away with. Fines have bankrupted companies and big breaches have led to fines that were surprisingly low. It's a lottery, for the most part.

This is hyperbole. His customers are probably running their business, not monitoring the news for info on every SaaS they use. PCI compliance most likely isn't what keeps them there: it's friction in leaving, customer service, possibly features they don't find elsewhere. There isn't some PCI police that has a list of all their customers and will email them.

If customers are lost, it'll be a trickle. Once they identify what's up, they'll be all hands on deck to fix it, and this amazing competitive advantage you feel fell into your lap will disappear. On the other hand, maybe he'll ignore it - I promise you there will be customers that really don't care. Yeah, they should. But they won't. Your competitor will still be in business

I'd turn it into a marketing advantage, not treat it like a magic torpedo. Many of our competitors outsource their programming or are resellers of one of our competitor's services. (In our industry, whoever has your data has a list of your customers, so important to control who has access to that information) In our pitch, I tell them to ask whoever they do business with, even if it isn't us, if they outsource their operation and who controls the data. In your situation, point out that some companies in your space, without naming names, store their payment data incorrectly, and why that's bad. Then hit them with how you are PCI compliant.

Another thing to consider: if your magic torpedo scenario doesn't play out, then what? There's people out there using a provider that stores payment details insecurely. Announce it publicly, and you've just made them a target for a breach - big payday for those hackers. Muahahahah, I've killed my competitor! Maybe, maybe not, but you've also just screwed over those customers. Even if they leave that provider, when they find out the reason their credit card is being abused is due to your disclosure, there's 0 chance you'll their business, and it could have long term PR repercussions. Hell, depending on your jurisdiction, potential legal ones.

(Yes, everyone will say it's not altron's fault - it's his competitor's. It's both at that point. If I tell the world about someone I don't like who leaves their house unlocked, I'm an asshole, and don't deserve to be liked)

About the only situation where I feel this works out well for you is to contact the customers of theirs that you know, and tell them directly.

The payment processor that the competitor uses can stop processing their transactions. While I was in the PCI consulting space a few years ago, I saw many cases where small and medium sized companies ended on the credit companies black list and no payment processor would dare take their business.

If he advertises PCI compliance, yes, bust his ass for lying. If he doesnt - thats a gray area ethically to me.