http://mivo.truxoft.com
MIVO!
miva beyond limits

MIVA^®  SECURITY:  Authorize.net Security Flaw

by Ivo Truxa, 06/15/2002

1. Background
2. News articles
3. User List postings
4. Module Patch
5. Useful links
6. User Comments

top

Up to June 2002, Authorize.net did not protect accounts of their customers and did not inform their customers about the necessity to protect themselves.

Anybody who knows your account number at Authorize.net, or who finds it when sequentially scanning numbers, can pass unlimited number of authorization requests through your account to Authorize.net.

Why should he do it? Hackers need to check which of their stolen CC# are still valid and accepted. Each CC costs you authorization fees even if no payment is being really submitted. Some Authorize.net customers reported many thousands of dollars lost in such fees. Authorize.net profited from it and was not interested on a solution until it was criticized by Bob Sullivan, MSNBC in his articles. The first article was initiated by angry Authorize.net users, the second one was written after more users were criticizing the issue on the Miva Merchant User List and I have forwarded the information together with a technical analysis to Bob Sullivan.

Unlike Authorize.net, Miva Co. reacted very quickly and changed the payment module so that it sends the password with every authorization request, not only at capture transactions as was requested in Authorize.net specifications. In the same time, I have also posted a patch of the authnet.mv module that was sucessfully applied to Miva Merchant 2, 3 and 4 versions by multiple users. However, the change in the module has no impact on the security of the Authoize.net account as long as you do not change its settings at the Direct Response method to require passwords always. Unfortunately, by default, the option was disabled.

Recently, Authorize.net updated their system, causing that carts using the Direct Response method stopped to work reliably. Users were reporting missing and duplicate orders form many weeks and again Authorize.net only went on claiming that there are no problems. Later they change the policy telling that the fault is in Miva Merchant (although nothing has changed in the thousands on Miva Merchant installations) and not in their system, in spite of the fact that it was this system that was just changed.

As of June 14th 2002, Authorize.net contacted Miva Co. telling that they have found and fixed the problem. It took about 8 weeks, killed business of many merchants who did not switch to another payment method soon enough and cost huge amounts on lost orders. Authrize.net refused to take the responsibility and will not pay any reimbursements.

top

Bob Sullivan, MSNBC wrote two articles about this issue:

• Net thieves find new way to nab cash
• ‘Brute force’ card thieves attack

top

The entire thread may be found in the Miva Merchant User List archive. There is much more information about the subsequent problems in the archies too.

Okay here is the info that I have

I will start at the begining

about 3 weeks My client got 7000 transactions sent through his authorizenet account for odd amounts of money IE $.02, $1.50, .37 ... none of the my clients products are under $3.00, none of the them came through the store so after getting to the root of the problem, some professional credit card thieves figured out my clients Authorize net account # (they did not Hack my system)not the Password just the account #, I got the account closed. I spoke with Ecommerce Exchange they handle the acctual bank gateway, they are ones that told me someone figured out the account #, this is not the first time this has happend to users. Anyway my client recieved a bill from his bank for $4500, $.35 for every transaction, no credit card was billed because they did not have the password but the transaction went thru the gateway. During the investigation on what went wrong Authorize net said I need to Contact Miva and see is they can set up the Password Verification Vice the account verification, at that time the Miva Rep said that they didn't have anything like that, so I called authize net back and set up the referal URL verification.

Once I setup the URL system, for about a week no sales, mind you this is a somewhat new site we get about 30 sales a month, I went into the store did a test order and recieved the UNABLE TO PROCESS ERROR so I called Authorize net and told them we were using Miva Merchant 4.12 and they said referal URL's will not work with Miva because Miva uses Direct response, They told me without the URL Verification or the Password Verification that someone could figure out the account # and setup a payment form and bounce CC's thru it to see if the #'s are good. So I called Miva back today to see why they offer a Gateway that had a Flaw in it adn they new about it, they said that the fix is due out in the next revision of the software and sent me the updated module. Aparrently authnet.mv version 3 is still being used in the Merchant 4.12, anyways I hope that clears some things up on what the whole is and how to fix it.

this is my setup I am running Merchant 4.12 with the latest OUI, all of my Authorizenet settings are correct.

top

posted to Miva Merchant User List on 4/14/2002
 

For those who want to fix their Authorize.net payment module so that the Authorize.net Direct Connect may be set into a mode requiring password ALWAYS, there are instructions here.

In MM v4.12, around the line 1430 of the Merchant2/modules/payment/authnet.mv file, in the function PaymentModule_Authorize( ), there is the following line beginning with:

Add the following line in front and insert x_Password into the l.fields assignment as follows:

Then go to your AuthNet account console, Options » Direct Connect and at the bottom of the page set Password protection to YES. Test your store. Do not forget to make a backup copy of the file before making any changes.

The patch was sucessfully tested on version 2.xx, 3.xx and 4.xx. MM v4.13 already contains the right code.

In relation to the described changes at Authorize.net, old Miva Commerce Library for Authorize.net started to return error messages containing potentially compromising data like user account numbers and Authorize.net account passwords. Please be sure to update the library to the current v3.94! See also the MIva Empresa Release Notes v3.94.

top

top

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2008