Multiple API Login IDs

[scottm]

This has probably been asked before. I did search, but didn't find anything, although I may not have searched for the right terms.  I do apologize if this has been asked before.

Is it possible to have multiple API login IDs?  One with lesser privileges?  Specifically for the CIM API method, but I guess this would be beneficial for any of the API methods.

For example, have one API login that links to your Authorize.net account, but it does not have the privilege to use the CustomerProfileTransactionRequest.  So you could use this API login ID on a public web server, without risking that server being hacked into and the hacker being able to run charges on the information stored in your CIM.

I know every effort should be made to protect this API login so that that doesn't happen.  But I just thought it would be more secure having this extra layer of protection.

Then you could have another API login ID that is linked to the same Authorize.net account that has all privileges, privileges to run transactions.

Is this possible to do?

Thanks

Scott

[stymiee]

This layer of protection does not currently exist but it sounds like an interesting idea. Maybe the team at Authnet will consider adding this to their to do list?

[Michelle]

Hey there,

I will definitely pass that on to our development teams for consideration. Thanks for the suggestion!

Thanks,

Michelle

Developer Community Manager

[CDeCinko]

Michelle, what is the status of this development request?

---

Michelle wrote:

Hey there,

I will definitely pass that on to our development teams for consideration. Thanks for the suggestion!

Thanks,

Michelle

Developer Community Manager

---

[Michelle]

Hey there,

No updates that I'm aware of. But the developers are aware of the request.

Thanks,

Michelle

Developer Community Manager

[TJPride]

Practically speaking, if a hacker gains access to your FTP, you're screwed. Period. Even if you don't store credit card info locally (and I'm sure you don't, since you're using Authorize.net), all the hacker has to do is insert 3-4 lines of code into your form and have it log the credit card info to a file. Same with customer data. Surface "hacks", on the other hand, are generally limited to inserting Javascript that forwards people to an infected site, unless you're a really moronic programmer and don't escape your data before putting it into a database query.

Short version - this might be an interesting idea for Authorize.net to implement, but I don't really think it'll enhance security that much. Just don't leave your password lying around.

[scottm]

That is correct.  If you're account is hacked into, you are screwed, and every effort should be made to protect this login information.

But, in order for a web facing script (a publicly accessible webpage, an order form for example) it has to be public and on a server that has a connection to the Internet.  This means it can be hacked.

Perhaps a script becomes vulnerable and a hacker gains access to the authorize.net script through that vulnerability (always keep your script up-to-date, but what about the event of a 0-day exploit?).  Perhaps your FTP username and password information leaks out, again this is the fault of the end-user for not protecting it better, but it could still happen.

The point I'm trying to make with this feature request, is that by having a more "write-only" Authorize.net login on your public facing application, then if your webhosting account gets hacked into, for any reason, the hacker conceivably would not be able to run charges on the cards that already exist in your CIM Authorize.net account.

I know I would feel safer with this.

Have a public facing script, that reads an Authorize.Net login, connects to the Authorize.net CIM database, writes the credit card information to the Authorize.Net servers and that is all it is capable of doing.

If I want to charge a card in the CIM database, I use a separate login, on my own personal local area network, behind a firewall which does not allow incoming web connections, to make that charge.

Yes, if you're public facing website is hacked, you are screwed.  Nothing will stop a hacker from injecting code into the scripts to email them the credit card information or write the credit card information somewhere else.  But at least they wouldn't be able to make charges on the cards already in the CIM database.

Look at the current situation.  On the public facing web server, you have to have your Authorize.Net information stored somewhere on the server. Somewhere where the webhosting account in question can read it.  If a hacker or malicious user can read that information, then they instantly have access to charge the cards in your CIM database for whatever amount they want, whenever they want.

Unless I'm missing something somewhere, which I won't say that I'm not.

[TJPride]

You need the payment profile ID to do any charging, however, so as long as you don't allow the public database user to access that information, you're still fine.

[scottm]

I have to admit, I haven't looked at any of this since I opened this thread last fall.

From the code I have, there is a vars.php file.  In it, it lists your authorize.net login name ($g_loginname) and transaction key ($g_transactionkey).

Can't anyone that has this information use the API to call getCustomerProfileIdsRequest to get a list of the Customer Profiles and charge a profile with that?

I really don't know, that's why I'm asking these questions.  It still just seems to me that if there was a login name and a transacation key that you could put on a public facing server and the only thing it could do, the only api functions it could call, are functions that write items to the CIM database.  This eliminates any potential malicious actions that can come about with this information.

[TJPride]

Hmm. I guess that would be a security flaw, if we assume for the sake of argument that your hosting has been compromised. However, the worst they'd be able to do is charge the credit cards and have the money go to you, so you could easily identify that someone's in your account, reverse the charges, and change your passwords. It would be much worse if they just added a credit card sniffer, as I said before, and then charged the credit cards somewhere else. If your hosting has been compromised, then having ANY part of ANY merchant system on your account is real bad. Having some of it locked off just delays the damage and/or forces the hacker to be slightly more creative.