PCI vulnerabilities

[ILoveHostasaurus]

Re: PCI vulnerabilities

The purpose of pci compliance is so that VISA/MC and merchant account providers can take even more money from the victims of fraud since none of the requirements actually do much in the way of stopping it. If a given vendor is not pci compliant and someone steals a credit card number from that vendor and uses it to rip an innocent merchant off, then supposedly they can hit that original vendor with a big fine.

What's the purpose of the fine? No idea since it doesn't go to help the merchant who was ripped off as the result of the poor security practices of the vendor which is what you'd think it would go to.

My personal favorite pci compliance point is failing email servers for allowing connections using weak SSL encryption but not failing them for allowing no encryption. So basically it's ok to send your password in clear text but it's not ok to encrypt it using something that still may take quite a while to crack.

[d_host]

Re: PCI vulnerabilities

What am I not understanding about this since it seems that card fraud is actually profitable to the credit card industry entities.

And that is precisely why we will not see the situation change anytime soon - unless something really major happens, like an international class action lawsuit or governmental inquiry into the situation. Banks and credit card companies couldn't care less about credit card fraud - they make money on both ends + chargeback fees, so they have zero incentive to remedy this problem. The PCI compliance is just adding insult to injury, if you ask me. It's not like if you do pass the PCI test they will at least side with you (the merchant) to recover lost revenue and product, or even waive the chargeback fees. It's a single-sided, self-serving system that makes them money and in return offers absolutely nothing to the merchant - no protection, no help with chargebacks, and not crediting the merchant for fraudulent transactions.

[Barrett]

Re: PCI vulnerabilities

What about using alertsite.com for this and just start dumping the Mcaffe services in droves due to their apparent overreaching blanket decision on this cookie thing ?

In General I find it curious the motivation for all this PCI crap since it is my understanding still if there is card fraud,

1. the merchant loses their merchandise
2. the merchant loses the money for the merchandise
3. the merchant loses more with the charge back fee
4. the merchant loses the discount rate both ways
5. the criminal is happy with new surf board
6. the banking industry is happy with all their additional profits for the fees and charge back fee

What am I not understanding about this since it seems that card fraud is actually profitable to the credit card industry entities.

[wcw]

Re: PCI vulnerabilities

I guess a first and last name would be user specific data. Is 5.07 going to effect all cookies or just the htscallerid?

Rick or Mark -

The concern I have is if you have
<META HTTP-EQUIV="Set-Cookie"
CONTENT="foo=bar;expires=Friday, 05-Sep-08 23:59:59 GMT; path=/">
in a page template, would miva merchant set it based on the 5.07 flag for SSL? Or would 5.07 have no effect on cookies set in the page templates?

[ILoveHostasaurus]

Re: PCI vulnerabilities

Does mcafee consider every cookie "potential sensitive". When I look at the cookies in my browser set by bankamerica.com there are several. Only one of them is listed as "send for: encrypted connections only". The others are for any type of connection. Is bank of america's connection vulnerable? Would they pass mcaffee's testing?

If the cookie holds anything that uniquely identifies you, then it would cause mcafee to fail them. So, if the cookie in question is just to make sure that when you visit their site, your choice to keep some box displayed on the page is remembered, that would not be an issue, however if the cookie is so they can pre-load the account access id, then that is a problem according to mcafee. I don't think they know the difference though from an automated testing perspective, so I believe they would fail mcafee regardless and have to prove to them otherwise that the cookie isn't revealing user-specific data.

[Rick Wilson]

Re: PCI vulnerabilities

McAfee's perspective is that ALL COOKIES are sensitive, even if there totally blank.

[wcw]

Re: PCI vulnerabilities

I use hacker safe (mcafee) and have been getting the following error:

Potential Sensitive Persistent Cookie Sent Over a Non-Encrypted (SSL) Channel
SSL Protocol Version 2 Detection

Does mcafee consider every cookie "potential sensitive". When I look at the cookies in my browser set by bankamerica.com there are several. Only one of them is listed as "send for: encrypted connections only". The others are for any type of connection. Is bank of america's connection vulnerable? Would they pass mcaffee's testing?

[Rick Wilson]

Re: PCI vulnerabilities

Does that basically make every page use https? How do large scale sites like amazon and newegg handle cookies so that they don't flagged?

No, 5.07 will not force every page secure, but it will use SSL to set the cookie on the shoppers computer.

[d_host]

Re: PCI vulnerabilities

Does that basically make every page use https? How do large scale sites like amazon and newegg handle cookies so that they don't flagged?

I don't think they use Macafee Secure (previously known as ScanAlert HackerSafe). Other PCI compliance companies are not yet flagging the persistent cookie issue as a vulnerability worthy of removing the certification from your site - although we have seen ControlScan already send notices about it - though at this point this doesn't remove the PCI certification status from your domain - it's more of an informational item *at this point*.

[d_host]

Re: PCI vulnerabilities

I think this whole shared SSL issue will probably go away pretty soon, with how the PCI Compliance scanning is done and how Visa/MasterCard/Discover/Amex want security to be implemented. Not only that, but hosting e-commerce sites in shared hosting environment by itself may very possibly change soon, too. We were at the hosting conference in Chicago just last month and there was a session on PCI Compliance, and the general consensus is that for a site to be truly PCI compliant under the new compliance rules, the site cannot be hosted on a shared server. This is supposedly something that Visa/MasterCard want to start implementing as soon as October 11th, but I don't think it's going to work and be an overnight requirement - there are way too many e-commerce sites on shared servers that would be impacted by such short notice (or lack of notice, really, as other than talking direct to PCI companies or Visa/MasterCard, I don't think anyone was sent any notices about this yet).

There was a number of hosting companies that already force their clients to upgrade to dedicated servers if they want to be 1) PCI compliant and 2) have daily security scans. I can see #2 being an issue - having a number of sites scanned on a shared server every day, on top of all the webbots spidering these same sites often simultaneously, is creating sometimes very high loads on these servers. Especially on larger sites that have thousands of products and take several hours to get scanned and spidered every day. I'm not convinced, though, that sites "must" be on dedicated serves to be PCI compliant... although I can see how one site having a script that can allow privileged access to the server could affect other clients' security and PCI status, so perhaps that's the direction credit card companies and PCI scanning companies are taking... Either way, this whole PCI compliance thing is reshaping the hosting environment for e-commerce sites, and we will very likely see a lot of changes over the next couple of years. What we see now is just the tip of the iceberg.

[Brandon MUS]

Re: PCI vulnerabilities

Does that basically make every page use https? How do large scale sites like amazon and newegg handle cookies so that they don't flagged?

[Rick Wilson]

Re: PCI vulnerabilities

Sure, we're allowing a setting in the Miva Empresa 5.07 engine to force cookies into secure mode. So if you choose to make Cookie Secure=Yes then all of your cookies will get set using SSL.

One caveat to this, it will NOT work with Shared Certs. This is a byproduct of McAfee's interpretation of PCI, which under their logic it's not possible to be PCI Compliant and use a shared cert.

5.07 doesn't force cookies secure, it allows for that to be a setting.

[Brandon MUS]

Re: PCI vulnerabilities

Can Miva or David provide a little more information about how Miva is going to be fixing this "issue"? I have systems that share cookies with Miva, so I want to make sure they will remain compatible and that both will be considered "secure".

[d_host]

Re: PCI vulnerabilities

Rick (seahawkfan that is),

We have the beta release of MivaVM v5.07 - if you'd like us to install it on your domain - simply open a support ticket with us and we will put it in place.

[Rick Wilson]

Re: PCI vulnerabilities

It's also worth noting that if this issue was a real security issue and not of McAfee's making we'd be moving mountains.

Since you're still PCI Compliant and there is no real security issue, we're moving diligently but not rushing.