cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Woocommerce Auth.net AIM - New SHA512 Requirements

I'm stuck...

We are using BlueHost with a VPS.  When Auth.net advised they were moving away from MD5 and upgrading to SHA512, I contacted BlueHost support to find out what I need to do.


I was told our VPS was using MD5 as the password hash.  And, they wouldn't help me move from MD5 to SHA512 as we aren't on a "Managed Server".

 

Being that I'm using the Latest WooCommerce on Wordpress, and using the lastest WooCommerce developed Auth.net AIM Payment Gateway, what do I need to do to be compliant with the new standards set by Auth.net?

 

Thanks!

Rick

rfree190
Member
1 ACCEPTED SOLUTION

Accepted Solutions

@rfree190 

 

Yes that is the general idea. Ultimately everything happens on your server because that is where your web application is hosted.  But yes, the sha512/md5 are not handled by adjusting server settings. They are handled by editing the source code of your web application.


Here is how it works:

 

-First a transaction is submitted by a customer on your website, when they click the button that charges their credit card.

 

-Second authorize.net sends your website a response with the result of the transaction. The response will contain a hash, which will be a long string of alphanumeric characters. The purpose of the hash is for your website to identify that the results of the transaction are actually coming from auth.net, rather than a malicious actor who is  posting data to your website in an attempt to compromise it. It is a security feature, in other words.

 

-Third, your website will have server side programming (meaing the actual files that make your website work will have programming scripts that are ran by the server) that gets the hash from the response. You website will then calculate its own hash, again through programming scripts, and if the two hashes match your website will know that the response is legitimate and can be acted on.

 

In your case, I would recommend hiring a developer to simply remove the hashing function from your code and accept all responses. You are using AIM and your responses are sent over a TLS connection.  You are already very secure before the hash.

 

The reason I say hire them to turn off the hash validation rather than programming a new sha512 to replace md5 is that the latter option will cost you much more money.  And FYI, the fact that you ask this question suggests that you do not have regular contact with professionals who help you with your site.  This is not a good thing when you have an SAQ D scope integration. I would advise you extremely to look into your PCI compliance status.  You self attest to this every year, typically, but at any time you are subject to an external audit.

 

The list of requirements to be PCI compliant with your integration is 67 pages or so of bullet points and they impose a large cost if you are going to comply. The quarterly and annual vulnerability scans and penetration tests will probably cost $16,000 a year minimum if I were to guess.  If someone reports an issue with your store (whether true or false) and it triggers an external PCI assement, you will be  fined $200 to $400 each for every single transaction that has passed over your server if you are not in compliance, according to what I have read.  

 

Go to the PCI security council website and to the document library.  Look for SAQs then SAQ D. It will have the list of requirements. Disclaimer is that I do not work for PCI and am not qualified to give any advice to anyone on any subject. This is just what I would be doing if I were in your shoes. 

 

 

View solution in original post

10 REPLIES 10
@rfree190

I would highly doubt that your store is using an AIM integration. AIM is a SAQ D scope integration and CMS, Wix, etc all use SAQ A level integrations. You are most likely on SIM. When the customer goes to the payment form, are they redirected to a hosted payment page or is the payment page something you yourself or your web developer designed?

If you built it, then you are AIM or DPM. If it is a hosted payment form then you are SIM.

What you have to do depends on your integration method. In all cases it will involve editing the source code of your web application if you want to go to sha512. If you are using AIM you can just turn off the md5 and not use sha512. Neither are required for AIM. If you are SIM/DPM, you will have to edit the source code of your app so that it performs a sha512 hash verification, or you App will break when the md5 is axed for good.
Renaissance
All Star

Our store is built using WordPress and WooCommerce.  We purchased this plugin directly from WooCommerce; "WooCommerce Authorize.net AIM".  The customer completes their checkout directly on our site, using the Authoirze.net gateway.

 

From what I'm reading, and please, correct me if I'm wrong, all the Hashing happens using the plugin's code, and not any hashing algorithms on our server?  Is that right?  So, even if our server is still using MD5, all hashing on our site, during checkout, is using SHA512 (or what ever the plugin is coded to use)?

 

So, even though Authorize.net is ending support of MD5 Hash, my checkout code will still function correctly?

 

Thanks!

Rick

 

@rfree190 

 

Yes that is the general idea. Ultimately everything happens on your server because that is where your web application is hosted.  But yes, the sha512/md5 are not handled by adjusting server settings. They are handled by editing the source code of your web application.


Here is how it works:

 

-First a transaction is submitted by a customer on your website, when they click the button that charges their credit card.

 

-Second authorize.net sends your website a response with the result of the transaction. The response will contain a hash, which will be a long string of alphanumeric characters. The purpose of the hash is for your website to identify that the results of the transaction are actually coming from auth.net, rather than a malicious actor who is  posting data to your website in an attempt to compromise it. It is a security feature, in other words.

 

-Third, your website will have server side programming (meaing the actual files that make your website work will have programming scripts that are ran by the server) that gets the hash from the response. You website will then calculate its own hash, again through programming scripts, and if the two hashes match your website will know that the response is legitimate and can be acted on.

 

In your case, I would recommend hiring a developer to simply remove the hashing function from your code and accept all responses. You are using AIM and your responses are sent over a TLS connection.  You are already very secure before the hash.

 

The reason I say hire them to turn off the hash validation rather than programming a new sha512 to replace md5 is that the latter option will cost you much more money.  And FYI, the fact that you ask this question suggests that you do not have regular contact with professionals who help you with your site.  This is not a good thing when you have an SAQ D scope integration. I would advise you extremely to look into your PCI compliance status.  You self attest to this every year, typically, but at any time you are subject to an external audit.

 

The list of requirements to be PCI compliant with your integration is 67 pages or so of bullet points and they impose a large cost if you are going to comply. The quarterly and annual vulnerability scans and penetration tests will probably cost $16,000 a year minimum if I were to guess.  If someone reports an issue with your store (whether true or false) and it triggers an external PCI assement, you will be  fined $200 to $400 each for every single transaction that has passed over your server if you are not in compliance, according to what I have read.  

 

Go to the PCI security council website and to the document library.  Look for SAQs then SAQ D. It will have the list of requirements. Disclaimer is that I do not work for PCI and am not qualified to give any advice to anyone on any subject. This is just what I would be doing if I were in your shoes. 

 

 

Thank you for the info Renaissance. I appreciate it.

I will look into this and see about hiring someone to confirm we are all good.

 

Thanks again.

Rick

 

@rfree190 

 

You are welcome. That sounds like a great idea. I will be straight up and tell you that there is very little chance that you are in my estimate. I think your best option is to switch to a modern integration like Accept Hosted that is PCI SAQ A scope, which has only about 12 or 16 requirements which are easy to meet. 

 

Download the SAQ D reference first. The people who conduct the pen testing and vulnerability scans have to be people who have had specialized training and are certified, if my memory serves me correct. It will be in their requirements.  You're looking at a several thousand dollar initial bill most likely.  SAQ D is the most compliance intensive scope you can fall under for ecommerce at current. 

 

Regarding this thread, could you kindly mark this question solved? Best of luck to you. 

 

 

If itโ€™s handled by the plugin arenโ€™t the makers of plugin supposed to update the code?

I donโ€™t understand how to update from md5 to sha512, what file I need to edit?

Is there a guide anywhere how to do this?

@bikecod

Thatโ€™s how it usually works. If you manually change you will need to edit whatever file does your response processing. You could contact the developer of the plugin first.
There is no guide for how to edit the source code of your plugin. I have posted some working hash verification code. If you are not skilled at programming I would suggest you hire someone.

I tried contacting the makers of the Wordpress plugin but they are not responding.

For some orders I get the โ€œSHA did not matchโ€ message but the order goes through, so Iโ€™m assuming there is something wrong in the code, on plugin updates says they updated to sha512.

I just didnโ€™t know if I had to do anything on my side to make everything work right?

Should I regenerate the keys in authorize and paste it in again?