Daniel's Blog

Authorize.net provides card-not-present credit card authorization. In other words, they are a gateway to which you can submit a credit card transaction and receive a response programatically. They have a bevy of interesting security measures, mostly for fraud protection, but also to secure your password. With every transaction you submit your username and something called a “transaction key,” which looks to me like some Base64 encoded random shit, and I hope that’s what it is. At any time, you can log onto their admin interface and generate a new tran key and start using that either in 24 hours or immediately. This increases security, obviously, because you aren’t passing the password over the wire with every transaction.

The feature I’m interested in discussing is the MD5 field of the response. This field is constructed by taking the MD5 hash of your login ID, the transaction ID, the amount, and a secret value you set in the admin interface. When you get the response, you cram these four values together, take the MD5, and see if you get the same value.

Neat security trick, and that’s all they really say about it in the manual. But what’s the practical effect? You’ve just given some poor asshole’s credit card to the wrong site or whatever, and you get back the response saying “all’s clear” and look at the MD5: it’s wrong. What do you do? You’ve already given away your login name, your tran key, and a credit card number. What do you do now?

What if something was compromised? You first instinct will be to go to the admin interface and see what’s going on. Unless you pick up the phone instead, you’re going to go give away your password. Which protects all the data for your merchant account, like (for example) your business’s bank account numbers. If you do call, what are you going to say? The MD5 sum failed? To the monkey on the phones? At 3 AM? The boat’s already hit the ice berg, you just caught it within the first gallon. You’re still sunk, and Authorize.net is still sunk.

Moreover, if something were to go drastically wrong, what else might be going wrong? The gateway is basically an HTTP POST with a CSV result. It goes over SSL for security. A problem here indicates a problem with SSL, which means the management interface is also compromised, which is where you send your infinitely more important password. Lots of businesses work like Matterform, and only do AUTH_ONLY requests, meaning, if there is money in this account, authorize it, and we’ll pick it up later (called “capturing”) or cancel (called “voiding”). We have an accountant whose sole function is to go through the admin interface capturing valid-looking transactions. Which means the password gets sent every day. As soon as I took over such a site, I would invalidate all of the logins, and get all the passwords that way. I bet at least 30% of businesses do something like us, which would amount to at least a few thousand Authorize.net account names and passwords, all linked to actual bank accounts.

So the purpose of the MD5 facility is really only to alert you to a shortcoming in SSL. I have no doubt that such a shortcoming exists in SSL, but I find the utility of being alerted to it directly after compromising myself to be less than the effort (meager though it may be) to implement the MD5 checking in our AIM API. I welcome criticisms of my argument, though I suspect that they will boil down to liability, for which (though I cannot be certain as I haven’t read the contract) I do believe Authorize.net is quite responsible for.

Thoughts?