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

Brainwrap created an issue. See original summary.

TR’s picture

Assigned: Brainwrap » Unassigned
Priority: Major » Normal
Status: Active » Fixed

Ubercart 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.

Brainwrap’s picture

Thanks so much! No, the debug box isn't checked, so it sounds like I'm OK. Much obliged!

Brainwrap’s picture

(sigh) OK, I'm guessing that this is related to the *original* Authorize.net post; today they sent out *another* notice:

Over the next few months, we are making several updates to our systems that you need to be aware of. They are all technical in nature and may require the assistance of your web developer or shopping cart/payment solution provider.

Please read this email carefully, and if you need to find a web developer to help you, please check out our Certified Developer Directory at www.authorize.net/cdd.
Akamai SureRoute Reminder
Authorize.Net is now using Akamai to optimize our Internet traffic routing, which includes your transaction requests. Akamai helps safeguard against interruptions caused by issues beyond Authorize.Net's direct control, such as Internet congestion, fiber cable cuts and other similar issues. Using Akamai is currently optional, but will be mandatory starting June 30th.

Upgrade your website or payment solution today to take immediate advantage of Akamai's benefits. If your solution uses a firewall, please read the Akamai FAQs to determine what steps to take before June 30th to avoid disruptions to transaction processing.
RC4 Cipher Disablement
In an effort to ensure that all server-to-server communications with the Authorize.Net platform (both transactional and otherwise) maintain the highest levels of security, we will be disabling the RC4 cipher suite in the sandbox on April 29, 2016, and in the production environment on May 31, 2016.

If you have a solution that relies on RC4 to communicate with our servers, please update it to a current, high-security cipher as soon as possible. Please review our API best practices blog post for more information.
Transaction and Batch ID Reminder
In the coming weeks, due to system updates, it will be possible to receive Authorize.Net IDs (Transaction ID, Batch ID, etc.) that are not in sequential order.

For example, currently, if you receive a Transaction ID of "1000," you could expect that the next Transaction ID would not be less than 1000. However, after the updates, it will be possible to receive a Transaction ID less than the one previously received.

If your system has any functionality that expects Authorize.Net-generated IDs to be sequential, please update it immediately so that you will not see any disruptions.

Additionally, please make sure that your solution does not restrict any Authorize.Net ID field to 10 characters. If you are required to define a character limit when storing any of our IDs, the limit should be no less than 20 characters.

Anyone have any thoughts on this one?

TR’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.