the old e-gold hash is constructed by concatenating (sans delimiter):
PAYMENT_ID
PAYEE_ACCOUNT
PAYMENT_AMOUNT
PAYMENT_UNITS
PAYMENT_METAL_ID
PAYMENT_BATCH_NUM
PAYER_ACCOUNT
MD5 Hash of alternate passphrase (uppercase hex)
and then taking the MD5 hash (in uppercase hex) of the
result.
an example might be:
NULL
100998
1.00
1
1
123456
253001
ABC123ABC123ABC123ABC123ABC123AB
concatenated to form:
NULL1009981.0011123456253001ABC123ABC123ABC123ABC123ABC123AB
which would produce an MD5 hash we'll call X.
the non pretty part is X is also the MD5 hash produced using the values:
NULL
100
9981.00
1
1
123456
253001
ABC123ABC123ABC123ABC123ABC123AB
which would be a payment for $9981.00 USD equiv. to account 100, instead
of a $1.00 payment to account 100998.
it's hard to come up with a situation where this might be
used as a compromise (since paying a different account will
result in the use of a different alternate passphrase hash
for notification) so the result wouldn't jive at the remote end.
but it's not perfect, thus the V2_HASH upgrade...
which is documented in full in the e-gold shopping cart interface
specification at:
http://www.e-gold.com/docs/e-gold_sci.pdf
around page 15. it adds delimiters (':') to the sequence which
prevents the above ugliness. it also adds a few more fields
to the hash string: the actual payment ounces, exchange rate,
weight charge as fee, and a GMT timestamp of the transaction.
to get the best out of the e-gold shopping cart interface (from
a e-commerce programmer point of view) i'd recommend using a
unique PAYMENT_ID on each potential trip to the e-gold shopping
cart. store this PAYMENT_ID along with whatever details of the
pending transaction you need on your server. when you receive
a notification from the e-gold server:
1. check to see if it matches a pending transaction from your end.
2. check the hash.
3. use the history automation interface to query your e-gold account
history using PAYMENT_ID for extra verification of the spend.
performing just #2 is not bad, adding #1 and #3 give you
any extra confidence you want.
jay w.
[EMAIL PROTECTED]
> If I remember correctly, the way the hash is constructed can in some cases
> allow an active attacker to change the payment (IE: change the amount),
> while the merchant thinks it received the correct payment.
>
> It's not a very likely attack, but it should be fixed anyway. I couldn't
> find the details of the attack in my e-gold mailing list archives, but I
> can ask the person who discovered the attack to send them (the e-gold
> people should also have these documents).
>
> Edwin
---
You are currently subscribed to e-gold-tech as: archive@jab.org
To unsubscribe send a blank email to [EMAIL PROTECTED]
