"MD5 Verification failed" error for AuthNet_AIM under certain conditions

When using online contribution pages, making a contribution under these circumstances causes and error:

1. Using payment processor AuthNet_AIM
2. MD5 hash set in the control panel at authorize.net
3. Same MD5 hash set in CiviCRM processor settings OR no MD5 hash set there at all
4. Title of the online contribution page includes a quotation mark as the final character
5. I can't reproduce the error using the authorize.net test server, only when doing a live transaction using the live server. This may be because the test server doesn't seem to allow you to set up an MD5 hash.

When you make a contribution using the live page in this circumstance, it gives this error:

Payment Processor Error message
: 9003:MD5 Verification failed

Even worse, this is the behavior when this error occurs:

1. The web page shows this error and bumps the user back to the main contribution page (same as civicrm/contribute/transact?reset=1&id=19 where they started), giving the user the impression the transaction did not complete.
2. However, an email confirmation message is sent as though the transaction DID complete.
3. The transaction has indeed gone through authorize.net - it shows on both authorize.net and the person's credit card.
4. However the transaction is not recorded by CiviCRM - it can't be found by search and it's not in the DB in civicrm_contribution

My suggestions:

1. Strange behavior when a quotation mark is included suggests some problem with escaping/unescaping or ?

2. If the MD5 hash value is blank in CiviCRM's AuthNet_AIM payment processor setup then CiviCRM should simply ignore MD5 verification and should never throw this error at all. This is the way (and the only way) to turn of MD5 hash verification and so this is the way the CiviCRM payment processor should work. As noted above, this error does occur even when the CiviCRM MD5 value is blank.

3. Really, the MD5 hash checking should be disabled completely in CiviCRM's implementation of AuthNet_AIM.

According to the authorize.net documentation for AIM, "MD5 Hash - The payment gateway generated MD5 hash value that can be used to authenticate the transaction response. Because transaction responses are returned using an SSL connection, this feature is not necessary for AIM." See p. 36 here: http://www.authorize.net/support/AIM_guide.pdf

What the MD5 hash is supposed to do is verify that the response actually does come from authorize.net, and not something like a man-in-the-middle attack. However, SSL solves that problem as well, making the MD5 has redundant.

So what should be CiviCRM's response when an MD5 error occurs? There are two possible causes of the error:

#1. Man-in-the-middle attack has intercepted the CC info and given a fake transaction acknowledgement.
#2. The user has typed in the MD5 value incorrectly or some strange programming bug has thrown the error inadvertently.

#1 is never going to happen because of the SSL connection solution mentioned above. So essentially all MD5 has errors are down to cause #2.

So how should CiviCRM react when it sees an MD5 hash mismatch?

Option A. Assume the transaction didn't happen, cancel it.
Option B. Assume the transaction did happen and proceed with it--perhaps giving some kind of warning to system administrators, but not even bringing it to the attention of the end user.

Option A should only be used if the cause is #1--which (because of SSL) it never will be.
Option B should be used otherwise.

Or even better, Option C: Don't even use the MD5 hash at all, as the authorize.net documentation suggest.

I'm marking this a major, just because the whole MD5 hash thing has created quite a lot of headaches for me (and others, based on the discussion boards) plus the fact of wrong handling of the error when it does occur (and which may occur with other similar errors, see for example CRM-3790) compounds the problem.