Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hey folks,
I noticed that the expiration date, CVV and last 4 digits of the CC number are being stored in the uc_cim_payment_profiles table. Is this just because I have my settings wonky? Because it seems like the whole point of CIM is to avoid having to store any of this data in the database and potentially violate PCI compliance.
Any thoughts?
Chris
Comments
Comment #1
jfolwarski CreditAttribution: jfolwarski commentedI would think this would be a major issue with this module. I went into it thinking that it DID push all the data to Authorize.net. To my surprise it doesn't. I'm with Chris in thinking that the whole purpose of CIM is to not store any CC data in our databases and push all the data to Authorize.net. Figured I'd bump this up to major priority for who ever takes over the module or just to let people know.
Comment #2
SchwebDesign CreditAttribution: SchwebDesign commentedHere's the "Protect stored cardholder data" section from Security Metrics PCI Self Assessment Questionnaire. I hope this helps!
Comment #3
torgosPizzaThese three sections are pertinent: ("PAN" stands for Primary Account Number)
So, while it's acceptable for the last 4 digits of the card to be stored, it's a violation to store the CVV code. IIRC Authorize stores this along with the card number in their secure server, so there's no real reason for us to store it locally. I don't think it's a violation to store the expiry date, though. My preferred option is to only store the tokens locally and have everything get pulled via the API upon request, but perhaps that's not the most performant way of doing it.
If I can find time (a bounty would help!) I can potentially write a patch that fixes this.