43 replies to this topic

[HappyPappy]

Vger, on Aug 14 2008, 12:08 AM, said:

Within the UK, if you are on a website which uses 3D Secure, you can opt to bypass it on 3 occasions, but by the 4th occasion you must register for the scheme if you wish to buy from sites which use it.

Very true. This has happened to me a few times as a buyer. If a website's payment system tries to force me to register into a scheme like 3D or VBV etc, I just shop somewhere else where I can make a payment. I never go back to that site again. Funny thinking about it from the buyers perspective.

[Fleurtatious]

Speaking of e-Path... Where can I get said osc payment module? All I got was a link and a list of codes that had to be sent by the cart (like ceml for customer email)
Thanks
Scott-Leonard

[fxeq12]

Vger, on Aug 10 2008, 06:10 PM, said:

Someone just did. My company has 6 dedicated servers running and we've had to get several of them certified for PCI compliance, so I know exactly what is involved.

It's not just the website which has to be certified compliant, but the server the website is hosted on. For instance, even something as simple as keeping backup files online which have been renamed to use .bak as the file extension on your website will get your site failed. Having SSL v2 enabled for SFTP or SSH access on the server will cause a fail. Some scanning companies will fail the server if SSL v2 is built into POP3/IMAP services - even though it is not used. Having TRACK/TRACE enabled on the server will cause a fail.

Even if you do not store card data on your website you do store other customer data which has to be kept secure, such as Name, Address, County/State, Zip Code, Country, Email Address and Password for account access. For instance, is someone can hack the site they can get all transactions changed to different Shipping addresses than those chosen by the customers - effectively hijacking the shipments.

Some fools use the osCommerce Credit Card module, which does store card data in the database (unencrypted), and they then run them through an EPOS machine in a bricks and mortar shop they own. They do this because they've already paid for a Merchant Account and don't want to pay again to get a valid Internet Mercant Account - so they break their agreement with the card companies and use their EPOS terminal to process web based transactions.

You'll see posts on these forums from people wanting to capture and store the CVV number as well as normal card data, so that they can be run through an EPOS terminal. Storing CVV data on a Shared Server is completely against PCI regs and even against the law in many countries (the United Kindom for one). The United States is very tough on PCI compliancy now.

Unfortunately the scanning companies used for PCI compliance testing do not operate any common standard, so the conditions that have to be met will vary with each company.

Vger

Can you tell me what specifially is wrong to use the cc module if I am running SSL, a dedicated server, a fixed ip and then I capture the credit card information and then manually enter the card information into an internet merchant account.?

[Flyer5]

HappyPappy, on Aug 13 2008, 05:13 PM, said:

Very true. This has happened to me a few times as a buyer. If a website's payment system tries to force me to register into a scheme like 3D or VBV etc, I just shop somewhere else where I can make a payment. I never go back to that site again. Funny thinking about it from the buyers perspective.

Why would you decline your card issuers efforts to protect you?
believe me, I've had my card data ripped off by some scamming asians online and its not fun trying to sort it out. These schemes are free and are there for your benefit.

[GemRock]

Flyer5, on Oct 30 2008, 10:52 PM, said:

...These schemes are free and are there for your benefit...

NOt true (well at least not entirely true). these schemes were brought about by the card issuers to protect THEMSELVES, ie, once you take part in, or rather you are forced into, the scheme, and if anything happens then you are deemed to be the person who used the card no matter what the truth is, and any claim made by you to the card issuer/bank will be refused.
if you manage to lose your card/personal details then there is no reason why your password for the scheme would be safe.

Ken

[So_Not_an_HTML_genius]

I have read through the first page of this post and found myself somewhat agreeing at what is written, scratching my head at more, and feeling frustrated with the rest.

This is what we have found out through out PCI Compliance Scanning Vendor, Security Metrics. I am not promoting this company by mentioning them. As a matter of fact, there are many companies that are "supposed" vendors for this that don't know their a$# from their elbow.

Anyway, we are a merchant and have been for years, 14 to be exact. 95% of our business is done at outside festival, renaissance faire, reenactments, etc. Therefore we have been manually typing credit card numbers into a little machine all that time. NOT one chargeback, not one fake card and not one fee in all that time.

5% of our business is done over the internet. We recently had our site scanned by our PCI Compliance vendor. They had NO issue where our credit card and customer information is stored. Our SSL was unhackable! You would think this is great...well it is not!

Their new problems now are the possibilities of "redirects" from our initial INDEX page of our osCommerce store. Therefore, even if we had a "gateway" used someone like "paypal" just for the credit card info, none of that would help as they are telling us that the INDEX page of our osCommerce and the "cross scripting" available there is what failed us exactly.

Does anyone have that particular problem?

Here is an example: These are the particular scripts that have caused us to fail! Again, I can prove if necessary to this group that our SSL encryption passed with flying colors and had no warnings at all. Our failing and failure to obtain a certificate for our site is based ONLY on our osCommerce index page.

(prior to this shortcut would be my website and store page)
index.php?_a=knowledgebase&_j=search&searchm=<script>foo</script

login.php?login=<script>foo</script>

index.php?function=add_kom&no=<script>foo</script>

index.php?error=<script>foo</script>

"When you load these pages, please search through the source code for
<script>foo</script>. Because <script>foo</script> is returning in the
source, the site is potentially vulnerable to cross site scripting (XSS)."

login.php?ref='%3e%3cscript%3ealert(upb_xss.nasl)%3c%2fscript%3e

"Similar to the previous links, when the source code returns the scanner
is finding '><script>alert(upb_xss.nasl)</script> in the returning page."
I am open to anyone that would like to contact me if they have any solutions to these particular issues.
-KB

[perfectpassion]

Follow the steps in this thread to prevent cross site scripting and code injection

[GemRock]

KB: with your particular issues as mentioned in your post, i wish you good luck with all the tricks as suggested in the thread posted above, which i do not use (any of them), and IMO, are "over the top", some may do more harm than good (but then this is my own opinion).

Ken

Edited by GemRock, 01 November 2008, 00:45.

[toyicebear]

Just to clear one up misconception about PCI compliance.

If you pass the PCI compliance scan you can do the following:

You can use a payment gateway where the payment information is collected (ATT: NOT STORED) on your site but processed directly in real-time by the payment gateway.

To just pass the PCI compliance scan is not enough if you wish to store cc info.

There are very stringent regulations which govern how cc info can be stored, these will also need to be adhered to.

You will also need to fill out a PCI compliance form where you state that you have followed the regulations.

If you do and then not follow the steps you have signed off on, then just guess who's ass is in the sling without a reprieve if your data get compromised?

(Even if its not compromised and you just get "found out" , your ass will still be in the sling)

Edited by toyicebear, 01 November 2008, 05:23.

[So_Not_an_HTML_genius]

THANK YOU!!!!!!!!

I want to thank everyone who has helped me through posts, messages, etc.

We are now PCI Compliant and it was no thank you to my host provider, no thank you to my merchant services company, no thank you to the numberous people from our data processor who kept having to have everyone's manager call us to explain the mistakes that the person before them made in their conversations with us....

Instead it was thanks to this forum and the members here who take time to help each other out.

Thanks again!
Kelly

[bobsi18]

I'm just starting to look at this - I know I should have done it earlier, there are just not enough hours in the day. I'm wondering if any-one knows of a reliable company that offers free PCI introductory scans or the like? I'd like to get a bit of an idea of what I'm up for before I start full hog, but I don't want to run to some dodgy site that tells me my site is all fine, then hacks it... Does that make sense?

Is there a thread somewhere that discusses common reasons to fail PCI, that I could use as a starting block? (Am currently implementing many of the security addons mentioned in the thread that perfectpassion linked to).

Thanks for any guidance.

[bobsi18]

*Wish I could edit posts...*

Hey all, also wondering about payment gateways. There are two options if I use a payment gateway to process credit cards (referring to a payment gateway that also processes the payments, doesn't just store the cc details):
1) the customer is sent to the payment gateways site to enter details or
2) the customer enters details on my site and these details are sent to the payment gateway...

Am I right in assuming:
In number 1), it is probably easier to become PCI compliant, as no (credit card) details are being entered on my site [but tests etc still required for the rest of the site]
In number 2), it looks better for the customer, but it would probably be harder to get PCI compliancy?

Or is it likely to be the same hoops that I have to jump through to get there?

[Nimitz_1061]

bobsi18, on Dec 28 2008, 09:47 AM, said:

*Wish I could edit posts...*

Hey all, also wondering about payment gateways. There are two options if I use a payment gateway to process credit cards (referring to a payment gateway that also processes the payments, doesn't just store the cc details):
1) the customer is sent to the payment gateways site to enter details or
2) the customer enters details on my site and these details are sent to the payment gateway...

Am I right in assuming:
In number 1), it is probably easier to become PCI compliant, as no (credit card) details are being entered on my site [but tests etc still required for the rest of the site]
In number 2), it looks better for the customer, but it would probably be harder to get PCI compliancy?

Or is it likely to be the same hoops that I have to jump through to get there?

PCI compliance is never a one time event, and if you are accepting payments you are subject to a need for compliance management.

In my opinion, sending the customer to an outside page just complicates matters for no material return in terms of PCI compliance. It also adds the problem of how to make the cart aware that the customer did, in fact, pay for the order. Case 2 is the better option, almost always.

David

[GemRock]

i believe i have been living in planet earth, especially in the small business arena, not soem sort of 'planet gaga' bubbles, so quite aware of what the so called pci dss means to small businesses. one particularly aspect of my awareness is to do with the online payment process services offered by (third party service providers) paypal, google and protx, to name only a few. all those third party payment process services have made it quite clear that one of main reasons they provide their services ( and they have been able to made big profit on) is to take away the burden & hassle of pci dss off small business. incidentally, those good third parties provide a way of customising the payment page on their site so that it could look very much the same as that of the online shops. it is needless to say how many transactions and how much money has gone through those third party specialised payment services.
however good your own pci dss might be, i rekcon you can't beat those who specialise in it, unless you rae the like of amazon.com, in which case i guess you would have no time to come here discussing pci dss, and incidentaly, even amazon.com dares not to store customers CC details on live server(s) that are connected directly to the internet - they transfer the CC details immediately to a 'back office' server as soon as customers enter them, which is NOT connected to internet - they have been doing this from day one of their online business.
Ken

[WoodsWalker]

Using third-party service providers such as PayPal in order to do online business without the hassle of PCI-compliance is GREAT! (hundreds of merchants here on the forum are doing it this way)

Designing a sales interface on your own website and getting a PCI-compliance certificate is also GREAT! (I and lots of other osC merchants have done this)

Whatever way you do it, doing business is GREAT!

Just my super-positive two cents.
~Wendy

[HappyPappy]

bobsi18, on Dec 29 2008, 12:47 AM, said:

-snip-
Am I right in assuming:
In number 1), it is probably easier to become PCI compliant, as no (credit card) details are being entered on my site [but tests etc still required for the rest of the site]
In number 2), it looks better for the customer, but it would probably be harder to get PCI compliancy?
-snip-

Its actually a lot easier than you may think.

1. If the site is not touching credit card details in anyway then you don't need PCI DSS compliance. It would be like trying to get PCI DSS compliance for your car. The PCI standard states clearly that if the PAN (primary account number) is not stored, processed or transmitted then PCI does not apply.

I now have four osc carts all on shared hosting, no dedicated IP's and no SSL but I use the e-Path manual payment gateway so I'm accepting credit cards in absolute compliance to PCI. Trust me, I have looked into this directly speaking with Visa, as well as my merchant account provider (Commonwealth Bank). I've also contacted the Payment Card Industry Security Standards Council in the U.S. directly.

A good friend of mine is currently paying off a $15,000 fine so I have been very paranoid about all this and was only happy when they confirmed my arrangement keeps me in the clear.

2. If customer enters credit card on your site, yes, you must get PCI compliance. I don't agree entering credit cards on your site looks better for your customer. With me they get to see a professional gateway company in the business of security handle their credit card payment. My opinion is this is better than a basic shopping cart asking for credit card details.

Hope this helps.

[WoodsWalker]

HappyPappy, on Jan 16 2009, 03:37 PM, said:

... I don't agree entering credit cards on your site looks better for your customer. With me they get to see a professional gateway company in the business of security handle their credit card payment. My opinion is this is better than a basic shopping cart asking for credit card details.

I agree somewhat with HappyPappy (even though I am PCI-compliant and designed my own payment page, which my customers seem to like). These days, with folks becoming more accustomed to online shopping, part of their confidence is based on the fact that they increasingly feel they know what to look for as signs that the page is "legit". Many if not most e-commerce sites these days refer the customer to a gateway for payment. I don't think customers will be put off in the slightest by being referred to a professional gateway page to enter their card details. It's a great solution, and getting better all the time (from what I've heard).

~Wendy

[trevor-h]

Hi there,

I'd like to ask the original poster HappyPappy, about this e-auth claim:

Just because you enter the CC details manually, as opposed to a gateway system processing them automatically - how does this ACTUALLY make it any more secure from a fraudulent entry?

If an entry is acceptable to the credit card company, then I'm curious about what extra info you would have over that, to alert you to a potentially fraudulent entry? Do you look at the details and just get a hunch?

Please, could you elaborate as to what manual info would alert you to fraud, but would bypass the screening process that a gateway provider uses?

Thanks kindly, and the question is sincere, not sarcasm.

[clippers]

Hi

I contacted trustwave today to inquire about pci dss, i explained my situation of my online shop and happened to mention i have a street shop too and that we have a credit card machine that is enabled for 'customer not present' for any mail order transactions (which we don't do), hsbc never mentioned we need to be pci complaint for this, but trustwave says we do,

I did start a test questionare for the pci and gave up, now im confused as im trying to answer for both my offline (hsbc) terminal and online (protx) terminal.

I was wondering has any one else come across this situation before and how did they handle the questionnaire as they don't seem to separate the 2 terminals.

And am i wrong to assume ALL customer information stored (cards and address) are under the PCI DSS rules whether your online or offline? even if you only store them for a few seconds (online) and then they are destroyed (offline)?

[acceptcredit]

Some post read as if they are looking for assistance with being PCI compliant, and others read as if they are attempting to get around any given PCI requirement. If you are part of the latter you may be asking for trouble later, because 2010 will be a year that enforcement will kick into high gear. If looking for assistance, getting help is not that hard - you just need to know where to go.

MOST Processors now have a PCI plan in place, so you really do not need to do all the legwork yourself. Your Processor will notify you by mail about any requirements. In fact, you may have been auto-enrolled in your Processor's PCI program, so if you see a debit from your bank account from your Processor that you don't recognize, chances are it is for PCI Compliance.

If your intent is just to pass the requirements so you don't get fined, just follow the Processor's instructions. This means they have contracted with a Qualified Security Assessor to provide you a method of validation at a competitive rate. This will generally be the easiest and most cost-effective way to meet PCI-DSS requirements.

If you already have a QSA, contact your Processor so that you can provide a copy of the certificate, so that they do not penalize you for being non-compliant.

While I cannot answer "tech" questions, I can likely answer most questions you may have about non-tech PCI issues, so feel free to post and I will answer what I can. Just know that ALL merchants are required to be PCI compliant now, so do not think that it just applies to your web business.

Also, as a rule of thumb, you can process Internet transactions on a MOTO account, provided you have notified your Processor in advance.