Security concern regarding authorize keys on website front-end

[marcdebiak]

A client of ours has expressed concern that their Authorize client key and API login ID are exposed when the page source is viewed on checkout. Our team investigated and found this is being generated by the Commerce Authorize plugin.

If these credentials are required to be public in order to process transactions then we'd like to better understand why it's secure and necessary.

An example of the concern brought up by the client legal and IT teams is here:

the big concern is around “the public” (anyone with a browser and the knowledge to go to developer mode) can read API authentication to auth.net. After reviewing the API documentation for auth.net, having the auth.net keys opens up the ability to post cc transactions “to the Client account” or “acting as Client”. One would think that any fraudulent money would only go to the Client, however, with the return transaction ID (created by a malicious actor), the money charged can be refunded to a different cc or even straight into a bank account. So, if I were into such things I would:

Grab the auth.net key from the website console Buy a few stolen cc Create a script to charge $500 (or whatever) in a transaction (grab the auth.net answer and transaction id) Go back with the same or different script and refund “my” money to a different bank account, et voila, I just made $500 (or whatever)

Even if the above requires a little more skill, anyone with the keys can launch a DDOS against the APIs and make it look like they are Client transactions for which we get charged (I believe) or at least tread on Client’s reputation with the vendor

[knynkwl]

Also, it looks like Authorize.net suggests that the API Login key should be secure.

IMPORTANT: The API Login ID and Transaction Key protect your payment gateway account from unauthorized use and should not be shared with anyone. Be sure to store these values securely on a server separate from your Web server and change the Transaction Key regularly to further strengthen the security of your account.

https://account.authorize.net/helpCP/Account/Settings/Security_Settings/General_Settings/API_Login_ID_and_Transaction_Key.htm

[benlobach]

@marcdebiak, @knynkwl: Thanks for reaching out! In order for an Accept.js transaction to process, there are three API keys required, and the third key (Transaction Key) is never exposed to the public. Without this key, no action can be taken in regard to your Authorize.net account.

When using the Accept.js integration, both the API Login ID and the Public Client Key are required to send a request to the tokenization process from the user's computer. We're following the documentation as laid out in the Authorize.net development site, so you may wish to address concerns with both values being publicly available with their development team as we can't verify cards (and receive a payment token) without both values.

https://developer.authorize.net/api/reference/features/acceptjs.html

The values would both be secure if using our Authorize.net plugin with the Accept.js functionality disabled, but you will want to ensure that you're following PCI compliant standards as your server would be responsible for passing the payment details to Authorize.net.

If you have further concerns about the security or integration, we'd love to answer them! Feel free to drop us a line at hello@digitalpros.co.

[marcdebiak]

Thank you @benlobach

This definitely puts the client at ease and makes a lot of sense.