The hash is only present in the message from the eGold server direct to
the merchant (I believe - I hope I've not got this wrong!). So consider
the following scenario:
- I do a transaction with you (assuming you are a merchant).
- Now I watch someone else connect to your site (by snooping traffic - I
don't need to see details, just connections).
- Next I take the form that my browser carried to your site when my
purchase succeeded and I the payment batch number by one (so that it
agrees with the person I've just seen start a purchase).
- Then I reconnect to you site, as if I've just completed another
purchase.
- At the same time the victim has finished his purchase and the eGold
server has sent you confirmation of his payment (with a valid hash).
- You get my connection (I sneaked in ahead of the victim), check my
payment batch number and send the product to my browser (or to details I
then provide).(*)
Obviously, this has many points at which it can fall down - I have to
guess the next batch number (it may increment by more than one - but if
I wanted I could get a better estimate by doing several transactions or
counting connections made to the eGold server), the timing has to be
right, etc etc - but it is a *possible* attack. Checking all the
details in the form from the customer against the signed form from the
server makes it a lot harder (which was my point - it becomes impossible
if a random value is added as a baggage field).
Andrew
(*)If the delivery details are decided beforehand and the product is not
sent via the browser then the merchant may be less vulnerable.
Sidd wrote:
[...]
> As long as you are checking the hash, and tracking the batch numbers
> everything should be fine.
[...]
---
You are currently subscribed to e-gold-tech as: archive@jab.org
To unsubscribe send a blank email to [EMAIL PROTECTED]
