One of my clients just forwarded this message to me from Authorize.net...I know I'm not supposed to report security *issues* here, but this is a security *question*...I'm just wondering whether this is something that Ubercart users have to worry about or deal with?
Thanks in advance to any who know:
Important Security Notice from Authorize.Net
Your Payment Gateway ID: 1454522
Dear Authorize.Net Merchant:
On the evening of March 21, 2016, between 4:13 PM and 11:49 PM Pacific time, an error occurred following an Authorize.Net system update that resulted in some merchants receiving transaction responses that contained their customers' full, unmasked card number associated with the transaction, rather than the masked, last four digits (Ex. XXXX1234) normally included in the response. Our internal team identified and resolved the issue.
Based on our follow-on investigation, it appears some of your transactions may have been affected. As with all your transaction processing, these responses were returned via a secure, encrypted connection. However, we urge you to ensure you are not storing this unmasked data in your systems.
It is recommended that you promptly contact your e-commerce/shopping cart provider or web developer to determine whether you typically store the card number field from the transaction response data you receive from Authorize.Net. Please refer to the FAQs below for further details regarding the card number field and its location in the transaction response.
If you determine that any transaction responses from the timeframe above were stored in your systems and contain a full, unmasked card number (rather than just the last four digits), it's recommended you delete the full card number or take appropriate steps to securely store or mask the data to maintain your level of Payment Card Industry Data Security Standard (PCI DSS) compliance. Please contact your Merchant Service Provider or PCI DSS assessor for further information on PCI compliance or refer to the PCI DSS website.
If you have any questions regarding this notice, please review the FAQs below or contact Customer Support.
We apologize for any disruption this may have caused and thank you for being an Authorize.Net merchant.
Sincerely,
Authorize.Net
This information is subject to the confidentiality obligations in your agreement with Authorize.Net. Please do not distribute.
Unmasked Card Numbers FAQs
Which merchants were impacted?
Merchants using delimited, name/value pair API formats, specifically the legacy Advanced Integration Method (AIM), Server Integration Method (SIM), Direct Post Method (DPM) and Silent Post were impacted. Merchants using the Authorize.Net API, including XML, JSON and SOAP formats, were not impacted.
What is Silent Post?
Silent Post is used to post transaction response data back to a specified URL. Silent Post can also be utilized in conjunction with all transaction processing services to post transaction response data back to a specified URL. Merchants' ecommerce/shopping cart providers or web developers will be able to determine if Silent Post is being utilized.
What field name in the response contains the full card number?
Account Number (Note: This is the 51st field)
Where can I find documentation on AIM responses?
Pages 51 & 55 of the AIM guide at http://www.authorize.net/content/dam/authorize/documents/AIM_guide.pdf
What action do merchants need to take?
Authorize.Net is recommending merchants review whether impacted transaction responses with full card numbers were stored or cached in their systems. Merchants should then delete the number or ensure it is stored/masked appropriately for their level of Payment Card Industry Data Security Standard (PCI DSS) compliance.
How do merchants know which transactions were impacted in order to identify and take action?
Transactions processed using the above integration methods during the timeframe provided above may have received full card numbers back in the Authorize.Net response.
In order to locate transactions in your system, check for transactions submitted to Authorize.Net with a time stamp between 4:12pm and 11:50pm Pacific time on March 21, 2016.
Can merchants remain PCI DSS compliant if storing full card numbers? What if merchants have more questions about PCI DSS and how this issue may impact compliance?
Under specific circumstances and controls, merchants can remain PCI DSS compliant if storing full card numbers, but they would need to contact their Merchant Service Provider and/or PCI DSS assessor to discuss those requirements.
Please refer to the PCI DSS version 3.1 for information on Requirements and Security Assessment Procedures, specifically "Requirement 3: Protect stored cardholder data," found on page 34: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf
Why do merchants need to speak with their website developer, e-commerce or shopping cart provider?
In order to understand if, how, or where a merchant's system may have stored the full card number, as well as how to mask, scrub or delete the full card number from their systems, merchants need to speak to their website developer, e-commerce or shopping cart provider.
Doesn't Authorize.Net always include card data in the transaction response?
Yes, some card data is included in responses, but normally only the last 4 numbers of a card is passed back in the masked format of an 8-character alphanumeric value, e.g. XXXX1234, rather than the full 15 or 16-digit card number.
The only thing that changed during this incident was that the full card number was passed back in the card number field, rather than the normal 8-character value with last 4 numbers of the card number. As with all transaction processing, these transaction responses were returned via secure, encrypted connections between merchants' solutions and Authorize.Net.
Were either the Expiration Date or CVV code passed back in responses from Authorize.Net?
No. As normal, neither Expiration Date nor CVV code were returned.
Why should merchants contact their Merchant Service Provider (MSP)? Does Authorize.Net know who a merchant's MSP is?
A merchant's MSP is the institution that provides their Merchant Account, and is responsible for partnering with them on PCI DSS assessment.
Unfortunately, Authorize.Net does not know who a merchant's MSP is, and suggests locating the funding deposit statements in order to identify the entity that acts as their MSP.
Why was there a delay in notification of this incident?
An email was originally sent on March 23rd concerning this incident, however, some merchants did not receive the email. Therefore, Authorize.Net is re-communicating to ensure everyone has been notified.
Comments
Comment #2
TR CreditAttribution: TR commentedUbercart does not store credit card numbers.
I believe the only way this Authorize.net problem would affect an Ubercart store is if you have "Log full API response messages from Authorize.net for debugging" enabled in your Authorize.net settings at /admin/store/settings/payment/method/credit. The default setting is to have logging disabled. But if you have it enabled, because of this Authorize.net error, the full credit card number may be included in that response message and then might be stored in the Drupal {watchdog} table (see /admin/reports/dblog). I suggest you check your debug setting and your watchdog table to see if that's the case.
Comment #3
Brainwrap CreditAttribution: Brainwrap commentedThanks so much! No, the debug box isn't checked, so it sounds like I'm OK. Much obliged!
Comment #4
Brainwrap CreditAttribution: Brainwrap commented(sigh) OK, I'm guessing that this is related to the *original* Authorize.net post; today they sent out *another* notice:
Anyone have any thoughts on this one?
Comment #5
TR CreditAttribution: TR commented#2710231: Authorize.Net Technical Updates