I'm evaluating a credit card processor[1], and I noticed they are using MD5 as part of a salted hash algorithm to protect a secret key. Since I know MD5 is generally considered broken, this feels like a poor solution. **Is that enough of a criteria to reject them as our processor? Is it possible to demonstrate an attack?**

(If this ought to be on a different StackExchange site, please let me know.)

Here's the specific scenario, simplified to the salient points.

Credentials
-----------

First, I have a "secret key" of 30+ upperalphanumeric characters and symbols. (Say, `TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI`.) I also have an "merchant id" of 12 digits. (Say, `123456789012`.)

Publicly Accessible Payment Form
--------------------------------

Second, the simplified payment form looks something like this. (The real form would include other parameters like name and address.)

```
<form action="https://examplepaymentprocessor.com" method="POST">
    <input name="MERCHANT" value="123456789012" />
    <input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
    <input name="TPS_DEF" value="MERCHANT AMOUNT TRANSACTION_TYPE" />
    <input name="AMOUNT" value="10.00" />
    <input name="TRANSACTION_TYPE" value="SALE" />
    <!-- other input fields for credit card number, contact information, etc. -->
    <input type="submit" value="Make Purchase" />
</form>

```

The "tamper-proof seal" is the "digest" of an MD5 hash of, in this case, a "message" composed of a string concatenation of:

1. my secret key,
2. my merchant id,
3. the amount of the transaction, and
4. the transaction type

Thus, in this case, `MD5("TUQ1ICGIIIK/PSBKNDFK=GNKOTHMMDBI12345678901210.00SALE") = d550a25dfb97697f5be928953ee7cfc4`.

`TPS_DEF` allows the user to specify the specific content of the message—or, if you prefer, the secret key plus a salt. The message includes, at minimum, the secret key, but could include up to all other parameters on the form. My example includes the merchant id, the amount, and the transaction type.

Data Retrieval
--------------

The process to retrieve example transactions is similar. Through either a (not publicly accessible) HTML form or some other method to HTTP `POST`, I can get information about a given transaction. (Assume that I have a transaction ID given to me from the above procedure.)

```
<form action="https://examplepaymentprocessor.com/transaction_status" method="POST">
    <input name="MERCHANT" value="123456789012" />
    <input name="TAMPER_PROOF_SEAL" value="d550a25dfb97697f5be928953ee7cfc4" />
    <input name="TPS_DEF" value="MERCHANT" />
    <input name="TRANSACTION_ID" value="1234567890" />
    <input type="submit" value="Get Info" />
</form>

```

This will return information including all the contact details of the customer and the last four digits of their credit card number. Note that, again, you (or an attacker) can specify the `TPS_DEF` as desired.

Imagined Attack
---------------

Given that MD5 is vulnerable to a chosen-prefix attack, I've played with using [HashClash](https://code.google.com/p/hashclash/) from [Mark Stevens](http://marc-stevens.nl/research/), but that seems to create two new messages with certain prefixes, rather than creating a second message whose MD5 matches the first. It seems, though, that someone with their own secret key could potentially create transaction status request that, would hash in such a way that it would retrieve *my* data rather than theirs.

Questions
---------

* How likely is it that an attacker could falsify the "tamper proof seal" to imitate me? (*Either* for forged transactions *or* for getting customer & transaction information—the latter is what I think is most likely.)
* Are there other attacks that you can imagine or demonstrate?
* Would you reject this processor? (Note that they are a perfect match for us in every other respect.)

**EDIT 1:** Reading [this other question](https://security.stackexchange.com/a/19908/24891) makes me think that, since MD5 is still resistant to pre-image attacks, this particular situation is safe.

**EDIT 2:** I clarified my question about an attack to be about both forged transactions *and* stolen customer information.

[1] Not named here. Email me for specifics.