Authorize.net (A.n) has recently come under fire for inadequately protecting merchants who subscribe to their Internet payment gateway service. The scam doesn't involve stealing from the merchants directly, but rather taking advantage of poorly protected gateway accounts to search for valid credit card numbers. There are remedies for the problem, but it is up to the merchant to enable them. You can apply the lessons in this article to your merchant account, even if you don't use Authorize.net.
Here's how the scam works: A hacker writes a program that sends thousands of low-figure (e.g. one cent) credit card payments through your A.n gateway account. Most of the numbers are meaningless and are rejected. But once in a while, a number goes through successfully and BINGO; the hacker now has a valid credit card number. This is bad news for credit card holder of course, but it is nearly as bad for you, the merchant. The problem is that you get dinged for every transaction attempt, even the ones that fail. Some merchants have seen end-of-the-month bills totaling thousands of dollars in bogus transaction processing fees.
Before the hacker can submit transactions, he has to find a valid gateway account number through which to send them. Apparently, figuring this out isn't too difficult because of the way A.n assigns numbers. However, this information would be useless to the hacker if the account were properly protected from rogue transactions by a password or other security measure. In other words, your account shouldn't accept transactions from an unrecognized source in the first place.
How could this happen? Why would A.n leave this security hole open by default on new accounts? Their response to these questions is to claim that some e-commerce solutions (like shopping carts) aren't set up to pass a password to the payment gateway. I still think the accounts should be protected by default, and let the merchant choose to open it up if they want to use an unsecured e-commerce solution. Many other payment gateways REQUIRE that your transactions use a password.
The fact is that no one really thought this problem would happen. Why would you worry about someone trying to send money to you? After all, look how long it has taken for a hacker to figure out this method of probing for valid card numbers. I'd say the hackers were slackers on this one.
To prevent this kind of attack, you have two choices, and you can use them in combination. The first option is to reject transactions that don't come from a recognized source. The second option is to reject transactions that don't include a password. In general, the second option is more reliable, as long as you use a hard-to-guess password.
To reject transactions from an unrecognized source, the payment gateway has to give you a way to specify the URL of valid sources. You can usually set this option through the Web interface that lets you configure your gateway account. I believe this method is less secure because I'm sure there are ways to fake the origin of a message and make it look like it came from the expected source. A casual user couldn't do this, but a determined hacker could.
The other choice, setting a password, is also accomplished through your gateway configuration interface. Once you assign a transaction password, you have to make sure your e-commerce software uses that same password when it submits transactions. If the e-commerce software doesn't give you a way to specify the password, the payment gateway will reject even your valid transactions.
You should protect your gateway account carefully, even if you don't use Authorize.net. Use a password, and make it a good one. No one cares as much about your finances as you do, and even if it is possible to recover the bogus charges, who needs the aggravation of dealing with that? |
