New 
mrbyte
-
Posts
10 -
Joined
-
Last visited
Posts posted by mrbyte
-
-
My understanding is that 3.2.2 over-rules 3.2, thus CVV should never (in any circumstance) be stored before during after authorization...
However 1.1.2 of PA-DSS is interesting, and seems to totally contradict my understanding of it!
Thanks for the conversation, it's been illuminating.
You are most welcome ;-)
I can see how one would think that 3.2.2 would overrule 3.2, but I believe it's actually subject to 3.2. It's only the PA-DSS that is specific in each point that it's after authorization.
I've never advocated storing sensitive information beyond authorization, ever.
When it comes to protecting yourself/your business from liabilities do not take the word of internet keyboard warriors at face value. (especially when they are interpreted to favor their own practices)
Contact your own merchant account provider and get clarification on any issues/questions. (If you are "afraid" to mention your current practices to your merchant account provider then that itself should be a HUGE flashing warning sign that you are probably doing something incorrectly)
If you fail to do your "due diligence" and just plod on as before, one day you might get a very nasty surprise when you find out that lamenting "BUT I DID NOT KNOW THAT" or "BUT I THOUGHT IT MEANT THAT" or "MY INTERPRETATION OF THAT WAS" does not hold much weight when i comes to payment data security.
Quite right. One must do their own research.
I talked to my provider yesterday, and while I didn't make it a point blank question, I did mention it in passing, and there was no outburst of "you CAN'T do that!!!!"
However, I also found out that I was incorrect in my estimate of what a gateway will cost. So, personally, I will be getting one if my site passes 5 orders a month. (I had set my "trigger" at 10 per month before.) My provider didn't seem to think this was a bad thing.
-
Put on your reading glasses and read 3.2.2 and take note that outside of other card authorization information that CVV2 (card verification code) is specifically mentioned and that it should not be stored under any circumstances.
For anyone who are still unsure they should contact their merchant account provider and inquire about manually processing of orders where the payment information has been collected online.
Now flip over to the PA-DSS which adds a bit of clarification to PCI-DSS 3.2.2:
1.1.2 AFTER AUTHORIZATION (emphasis mine) do not store the card verification value or code (three or four-digit blah blah)
Aligns with PCI-DSS Requirement 3.2.2 (emphasis theirs...)
-
90% of addons need to be nuked.
------------------------------------------------
3.2, I believe (I cannot remember the exact words, and cannot be bothered to look), states that sensitive data is not to be stored. It is obvious to all that CVV is sensitive data...
Is there a note that says sensitive data may be stored if there is a business need and is secure? I can't remember that, but I'm sure there is if you say so.
I cannot foresee any shopkeep running osCommerce being secure enough to allow this. So it's really null and void, I'd say.
I've said before that a gateway is really the better way to do it, but it's been lost in the noise.
I quoted 3.2 above. That's straight off the PDF file from the PCI committee/council/whatever's website, and you can get it here: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf
-
You just can't fix stupid !
Chris
You're right, no matter how hard I try to fix you, you're still stupid, Dunweb.
I have the PCI spec in front of me, and 3.2 in it's entirety says:
3.2 Do not store sensitive data after authorization, even if encrypted. Sensitive data includes the data as cited in following Requirements 3.2.1 through 3.2.3
Now, do I need to continue, or are we all following along. Good. Note the note that says sensitive data may be stored if there is a business justification and it is stored securely?
Is it because you make so much money misinterpreting the standards? Or is it really just an inability to read, comprehend and understand basic English and how outlines and such work?
Either way, you are a profiteering blowhard.
As far as "Turning me in" go ahead. Good luck with that...
Cheers
-
I'm not using the correct terminology, CVV, CVV2, CV2... Whatever the 3-digit "magic number" on the back is called. PCI 2, section 3.2 specifically says it can be saved long enough to process and get authorization, and then must be deleted. It further states that it can still be saved, in a safe and secure manner if there is a valid business case to be made for doing so.
-
If you save the info and process it manually then you are taking a large risk for saving some pennies.
Even if you are in a country (or state) where you currently are not required by law to follow the PCI regulations, you are still liable for sanctions and fines from your merchant account provider, Visa and Master Card.
And if someone manages to sift payment information from you and it is shown that you have been lax in handling customer payment data, then this will impact your business reputation as-well as open your for civil suits from your customers.
Which could happen even with paper records from phone/mail orders. If someone were to use a manual module and NOT delete the CV2 info after use, that itself is a PCI violation, clear as day. So, while I agree with you about the consequences of a breach, I still do not believe that PCI or the law prohibit manual processing of credit cards.
According to the PCI DSS requirement 3.2, the storage of sensitive authentication data after authorization is strictly prohibited. "After authorization" is the critical bit here. And I maintain that mangling the number as I described above, and using SSL and other encryption when receiving the email off of the email server used for the store's domain, by which I mean the email is not sent anywhere outside the host, covers the encryption requirements of PCI for data transmission.
Someone makes the purchase, admin get's the info, processes the transaction and deletes the sensitive info. Compliance preserved.
I agree that a gateway is the best way, regardless of what my stance on PCI is. However, I also think that for a startup, that doesn't (yet) wish to pay the $20-50 monthly fees for a gateway, and already has a card-not-present enabled terminal, a manual option would be nice.
I'm talking a limited amount of processing here, say under 10 transactions a month. At that level, it's more than pennies to be saved. Beyond that, yeah, just the possibility of fraud or erroneous data entry alone should be enough for a responsible store owner to get a gateway.
My main objection is the misleading tone taken by others when this question is even asked. It *is* misleading to say that manually processing cards is illegal, and I've proven it.
But I will also say that processing a large amount of transactions manually is insane, opens you to fraud, errors and shouldn't be done.
-
The silence is deafening.
Now, to address the whole CV2 number problem, what I did in ZenCart's manual credit card module was to mangle the CV2 info. This is then emailed to the admin email address. Nothing in the email makes mention of the obfuscation of the CV2 number. I know the number is mangled, and I alone know what to do to unmangle it. After the CV2 number is mangled and emailed, it is not retained anywhere. Others wrote the module, I just added the mangle code.
Anyone looking at the code would know as well how to unmangle the number, however this is only to stop/delay someone that's managed to gain access to the admin and email of a given store. Anyone that installed this module would be informed as part of the install process.
I agree that a gateway is the best way, regardless of what my stance on PCI is. However, I also think that for a startup, that doesn't (yet) wish to pay the $20-50 monthly fees for a gateway, and already has a card-not-present enabled terminal, a manual option would be nice.
-
PCI DSS compliance was incorporated into the Canadian Privacy Act in 2010. Click the link to learn more. The act governs ALL of Canada.
Chris
From what I found, reading past the definitions is that the CPA governs GOVERNMENT entities.
The other stuff you quoted, obviously without reading, require reasonable safeguards to prevent breeches, require encryption for transmission of data, and set forth the responsibility in the event of a breech.
Again, nothing that prohibits the use of a manual card entry system.
So, while I'm partially incorrect in stating that PCI isn't law, you're also incorrect to state that manual entry is illegal.
I don't claim to be the PCI "police'. However, I have worked with several clients in several states that received Federal warnings after their sites were audited and failed PCI compliance policies. As Nick Mentioned above, there are several states in the USA and almost ALL of the provinces in Canada that now have LAWS regarding the handling of credit card information. I am confident that within the next year or so, that ALL states in the USA will have a law in effect governing the handling of electronic information collected. These laws will become common in an effort to fight credit card fraud.
I have been doing this for over 10 years, please don't preach to me about current policies. If you are MORE qualified than I am to speak on the subject, please state your credentials and post any relevant links that would contradict the information I have provided.
Chris
You may not "claim" to be the PCI police, but you act like it. As far as my qualifications, I haven't seen YOUR credentials, but I'm just a guy that's sick of the loudest mouth winning. Nothing you have quoted really does anything for your case; most of the material actually proves mine.
Cheers.
-
@J_Fyrebird
Well, there are no differences in the mail handling function between v2.2 and v2.3.1, I would guess it is the database tables that are the issue. If you would like detailed help, please post the site URL (to verify PCI DSS compliance) and I would be happy to help you with the tables and queries.
Chris
I realize I'm new here, and all, but really, I feel I must protest a particular point.
PCI DSS is **NOT** a LAW, it is a standard. Every time you bluster about the "illegality" of manually processing cards I cringe.
Visa and other issuers are not government agencies. They are businesses. At worst, violation of PCI standards is a breach of contract, a civil matter, and the "fines" involved are from Visa/MC/etc, not your local state/provincial governments. Furthermore, they are for *breeches* and not for solely being non-compliant, as I understand.
Finally, the PCI standards prohibit the *storage* of track data and CVV numbers. A PCI compliant manual processing solution *is* possible, but the way you carry on about the "illegal" nature of manually processing credit cards, folks seem to assume the loudest mouth is the wisest, or more likely, they just would rather not get involved in a urination contest with you over it.
Misuse of credit card information *is* illegal, but misuse would be, for example, taking the captured information and fraudulently using that to make charges.Misuse is *not* taking the information and using this information from your own customer to process a sale they have agreed to in the first place.
When I take orders over the phone I need the CVV to process. I don't store the number. When a customer emails me the information, I delete the email after I have processed it. While the email route may not be "compliant" it's not "illegal" and I curtail my risk of a breech by deleting the information after I've processed the order.
Please, stop trying to the the PCI "police."
If you still feel that PCI is a law, please post for me the federal or provincial statutes (for Canada) or the U.S. equivalent.
Cheers.
Free templates?
in Templates and Images
Posted
Guess it depends on the ability of the person. I'd like a free template that's close to what I'm after, then I can change it around to what I'd like it to be.