I wish that virtuemart did not store the CVV2 number in the database. The following document:
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf
In item 3.2.2 says that it is forbidden for anyone to store a CVV2 or CVC2 code. Encrypted or not.
These terms are shared by all credit cards, discover, visa, mastercard, amex etc. The terms and conditions of Authroize.Net and PayPal Pro say that you must follow these standards. So anyone using those services (and most likely all other card payment services) are in breach of their agreement as VirtueMart stores the CVV2 number (unencrypted) in the database. It is even emailed out on the order confirmation email.
I have created patch file against virtuemart 1.0.3 which stops the CVV being emailed or stored within the database. To apply the patch run the command:
patch < ps_checkout.php.diff.txt
patch is a unix (gnu) tool that you can get for windows. if you are on windows you can get the patch program at unxutils.sourceforge.net in their zip file. put patch.exe into your c:\windows\system32 folder. then "Start > Run.. > cmd.exe". then enter the command "cd \path\to\ps_checkout.php". then run the above command. you just have the diff file in the same folder. don't forget to make a copy of your original file.
If I can have a second wish it would be that the credit card input form would not remember the customer card details for added security- there is a patch here: http://virtuemart.net/index.php?option=com_smf&Itemid=71&topic=16424.0
[attachment cleanup by admin]
Could we get someone from the VM team to comment on this. Is storing the CVV2 code a common practice among shopping cart apps?
Quote from: spacebass5000 on March 24, 2006, 23:55:14 PM
Could we get someone from the VM team to comment on this.
* bump *
Quote from: spacebass5000 on March 24, 2006, 23:55:14 PM
Is storing the CVV2 code a common practice among shopping cart apps?
it is a bit of a moot point whether other apps do so or not. it is forbidden by every Internet merchant account and credit card agreement that we have read. if you sign up to any credit card gateway they typically say within their agreement that you are bound to the agreements of the card issuers themselves. e.g. if you except visa, discover, amex and mastercard via some payments gateway then typically you need to print out and read all of the card issuer agreements - not just the payment gateway agreement.
so typically your payments gateway agreement makes you liable to be audited by the card issuer directly. we know of firms that have had visa phone them and say "we are sending around our consultants to audit that you are compliant with both the terms and conditions of your gateway provider and our terms and conditions". that is a routine audit. not an audit because of complaints by anyone. that is business-as-usual for visa. the more successful you become the more likely that you will be audited.
at the end of the day if you are doing the correct thing then an audit should be welcomed. you can advertise the fact that you have been audited on your website to give your customers greater confidence in your store. peace of mind all round.
the existence of such "tie ins" between card issues and card gateways is why there is a Payment Card Industry (PCI) Data Security Standard at that link above. that is the card industry standard. we found that link by reading our agreements which lead to visa agreements which said you must be compliant with that PDF.
we are so 100% sure of this that part of our consultancy offering is helping firms who have had such a phone call start fixing their compliance issues before visa (or amex, or discover, or mastercard, or ...) arrive at their door. i am sure clients would like to say to visa when they arrive "oops! we just found out that we have some issues and have a plan to fix them" or even "we are fully complaint - here is our documentation to prove it - have a nice day" than get the bad news and be saying "pardon? PCI Standards? what are PCI standards?".
If you move into the realms of Credit Card processing there are a number of rules and regulations to follow. Visa and Master Card publish a Payment Card Industry [PCI] Security Requiments Standard. AMEX and Discover have their own versions but they are similar to the PCI document. When you sign up you will get a few pages of small print. The attached link takes you to an overview by Visa USA
http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf?it=search
Please note the rules defined above are core to processing credit cards and not just a requirement for certification
Requirement 3: Protect Stored Data is important and must be read by those involved in the CVV2 Discussion. Do not Store CVV2 data
In Europe the EU issues new rules and regulations daily about protecting personal information [these apply to commercial enterprises, the EU Governments flout these rules]. As we operate primarily in the US we are not up to date so check EU rules. When I was VP IT for a major European Company I had to fill in all kinds of forms on protecting personal data etc. As a small Merchant you may be OK
All sounds very complex but like everything else you only require to read a few documents to become an expert
When you get to the small print in the service agreements there are rules about returns, need to keep accurate records, proof of delivery etc., otherwise you take the hit if the customer claims he did not make payment or receive the goods, etc. There are special rules for downloadable products as proof of delivery can be difficult. If like us, you are the Merchant but other organizations do the order fulfilment [Shipping] you are also responsible to make sure that they comply with all rules
To get verified as a small Merchant you can do a self assessment but don't cheat. The Credit Card companies can decide to audit you and if you do not follow the rules and have a security breach you are in real trouble. Unfortunatley there is a lot of reading to catch up with but it all makes sense and when you know your way around you can start a business to advise on compliance!
Good Luck!
I have created patch file against virtuemart 1.0.4 which stops the CVV being emailed or stored within the database. To apply the patch run the command:
unix:
cd /path/to/vm/classes/
patch < ps_checkout.php.forbiddencvv2.diff.txt
windows:
cd \path\to\vm\classes\
patch < ps_checkout.php.forbiddencvv2.diff.txt
patch is a unix (gnu) tool that you can get for windows. if you are on windows you can get the patch program at unxutils.sourceforge.net in their zip file. put patch.exe into your c:\windows\system32 folder. then "Start > Run.. > cmd.exe". then enter the commands above.
[attachment cleanup by admin]
wow, more reading... i read so much, it is ridiculous
thanks guys!
i thoroughly appreciate your help :D
What this patch exactly do?
In my case, I use offline credit card processing. I always print a hard copy of the order and delete as soon as I get them so the info is never in the database very long. And I do have SSL license so the website is https://
My question is this:
When I turn ON the CVV so that on the order form, the customer has to enter the CVV.
When the order is completed, in the customer's email, no CCV. In my email of the order, no CVV. But in the order form in Virtuemart in the back office, will I still be able to see CVV?
JSG
Quote from: winfreepcs on March 28, 2006, 20:00:46 PM
What this patch exactly do?
[::snip::]
In my case, I use offline credit card processing.
sorry for not making it clear that this patch ensures that CVV2 is not stored anywhere in the database. so it only stays in the customers server side session. once the client has logged out it has gone totally. if you login you cannot see it. this is
not suitable for offline card processing if you want to use CVV2. it is however
very suitable when you use a card payment gateway such as 2Checkout, PayPal Pro or Authorize.net to take the payment automatically using one of the custom credit card payment modules for this purpose.
if you have not enabled "show CVV" on your credit card payment module then you do not need this patch regardless of your process.
i tested then looked in the database and deleting the order does delete the payment detail row from the table that normally stores the CVV. so you are definately not storing the CVV after you have deleted the order.
i would say that having the CVV on the email is very bad unless you control the email server - use TSL (ssl on the email connections - and pick up your email over ssl with pop3s or imaps). otherwise you are sending the CVV outside of your SSL certs protection. you can remove CVV from the email by finding the lines in ps_checkout.php
$payment_info_details .= $VM_LANG->_PHPSHOP_CHECKOUT_CONF_PAYINFO_EXDATE.': '.$_SESSION['ccdata']['order_payment_expire_month'].' / '.$_SESSION['ccdata']['order_payment_expire_year'].'<br />';
if( !empty($_SESSION['ccdata']['credit_card_code'])) {
$payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
and simply put a double forward slash
// at the front of the third line:
$payment_info_details .= $VM_LANG->_PHPSHOP_CHECKOUT_CONF_PAYINFO_EXDATE.': '.$_SESSION['ccdata']['order_payment_expire_month'].' / '.$_SESSION['ccdata']['order_payment_expire_year'].'<br />';
if( !empty($_SESSION['ccdata']['credit_card_code'])) {
// $payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
this simply removes the CVV from the email. if you dont apply the patch but just make that change the CVV will still be in the database so you can view the order in the site to see the CVV - do your card payment - then print and delete the order.
Thanks, that did the trick!
JSG
it has now occurred to me that my original post was reporting a problem with suggesting a workable solution.
the workable solution is to have two new options where the "show cvv" option is that default to the current behaviour
Email CVV: Yes/No
Store CVV: Yes/No
which means that folks like me bound my card gateway agreements can change these to No/No and folks like winfreepcs can change them to No/Yes and folks that dont know or dont care can leave them alone as Yes/Yes.
i will raise an issue and provide a patch.
Task #654 — options to control CVV storage and email
http://virtuemart.net/index.php?option=com_flyspray&do=details&id=654&Itemid=91&option=com_flyspray&Itemid=91
Quote from: simbo1905 on March 29, 2006, 11:59:34 AM
it has now occurred to me that my original post was reporting a problem with suggesting a workable solution.
the workable solution is to have two new options where the "show cvv" option is that default to the current behaviour
Email CVV: Yes/No
Store CVV: Yes/No
which means that folks like me bound my card gateway agreements can change these to No/No and folks like winfreepcs can change them to No/Yes and folks that dont know or dont care can leave them alone as Yes/Yes.
i will raise an issue and provide a patch.
You've nailed it and it's an excellent proposal for a feature.
I personally feel the default should be No/No because I suspect there are going to be merchants whizzing through this installation and put the shop live and not realized the CVV is showing on emails.
JSG
Hi simbo1905 -
Two questions -
1. Any idea what the status is on the task/enhancement you requested to show/hide, store/don't store the CVV code? Think this is a great enhancement, and think it is definitely needed...but I can't tell that there has been any movement on the task...
2. Do you know if your patches will work with the newest versions of VM? I'm on 1.0.6 now, with plans to move to 1.0.7 soon.
Thanks,
Philip
I'm runnung 1.0.7. Is this still an issue? Will the patch work?
Hi,
I wanted to see where things stood with the CVV2 issue. The last informational entry was around March.
I am running VirtueMart 1.0.9.
Is the process still:
Step 1
Run this patch
cd /path/to/vm/classes/
patch < ps_checkout.php.forbiddencvv2.diff.txt
Step 2
Edit this code:
you can remove CVV from the email by finding the lines in ps_checkout.php
$payment_info_details .= $VM_LANG->_PHPSHOP_CHECKOUT_CONF_PAYINFO_EXDATE.': '.$_SESSION['ccdata']['order_payment_expire_month'].' / '.$_SESSION['ccdata']['order_payment_expire_year'].'<br />';
if( !empty($_SESSION['ccdata']['credit_card_code'])) {
$payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
and simply put a double forward slash // at the front of the third line:
$payment_info_details .= $VM_LANG->_PHPSHOP_CHECKOUT_CONF_PAYINFO_EXDATE.': '.$_SESSION['ccdata']['order_payment_expire_month'].' / '.$_SESSION['ccdata']['order_payment_expire_year'].'<br />';
if( !empty($_SESSION['ccdata']['credit_card_code'])) {
// $payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
this simply removes the CVV from the email.
Any information is greatly appreciated.
Thanks,
Karl
Yes, I just upgraded a site and had to edit the files to remove CVV2 data. I prefer to edit these manually, in case something has changed as far as line numbers or such. Use ps_checkout.php.forbiddencvv2.diff.txt as a guide, you will see the line being edited, and the replacement code.
Great, thanks FrankZoid!!!
Yes.
Mine works in J 1.0.12 and VM 1.0.9
I also manage to hide all the numbers except last 4 of the cc number in the email.
Make sure you can read the full cc number and CVV in the order list in the backend.
JSG
Can someone please update this?? I am using 1.0.10 and the patch listed in this thread did not work. I received the following error:
Hunk #1 succeeded at 864 (offset -7 lines).
Hunk #2 FAILED at 1523.
Hunk #3 succeeded at 2199 with fuzz 2 (offset 85 lines).
1 out of 3 hunks FAILED -- saving rejects to file ps_checkout.php.rej
This is a VERY important issue, and I am a bit surprised it hasn't been fixed in a release yet, and there is not more documentation concerning it. I'm not trying to come across as a jerk, I just hate to think many people might be in violation of the T.O.S. and may not even know it.
Hi,
I just manually applied the patch to ps_checkout.php VM 1.0.12 and it works fine. I think the reason it doesn't work on 1.0.12 is that the line numbers are different.
To apply manually, do this:
- make a backup of ps_checkout.php; it's located in
/administrator/components/com_virtuemart/classes/
- Find this line:
$q .= "'" . $d["order_payment_code"] . "', ";
- Change to:
$q .= "'', ";
- Find this line:
$payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
- Change to:
//$payment_info_details .= 'CVV code: '.$_SESSION['ccdata']['credit_card_code'].'<br />';
Thanks a LOT for the patch. I don't need to get busted for story cc info.
this post has been very helpful.
guess next releases should take a serious look into this issue?
- g
Is this issue still open on the later versions? I'm running VM 1.1.12... I did a quick search for CVV in my db, and found no tables. Thanks in advance for replying.
Quote from: Frogdog on November 26, 2007, 22:25:47 PM
Is this issue still open on the later versions? I'm running VM 1.1.12... I did a quick search for CVV in my db, and found no tables. Thanks in advance for replying.
its because its encrypted.
- g
Ah...and now I see the post right above mine (duh) and the manual patch...will apply. I agree with FavoriteU, I'm surprised this is not already setup in the core VM files this way. Thanks for the reply, will fix right now.
Well, My questions is, if Im switching off the encryption on backend, and I want to store the full credit card details on the database, then where is it stored ?