0

Suppose a client places an order on an eCommerce platform. And then claims that they did not place the order.

How can we prove that the order was in fact placed by the customer assuming that we cannot trust the platform?

One example would be to see the server logs but that wouldn't work if we assume the platform is malicious.

In other words, what are the traces someone leaves when dealing with a website besides the logs on the platform itself? Equivalently, what prevents a website from placing an order on their servers on the client's behalf without the client's permission?

17
  • "How can we prove ...?" Who's "we"? What kind of proof is required?
    – schroeder
    Feb 26 '20 at 8:46
  • The traces are all on the systems in the chain around the platform. You use those to provide proof. This is why the pattern of issuing receipts exists.
    – schroeder
    Feb 26 '20 at 8:47
  • @schroeder I mean what tools do we have to settle such a claim of malicious server in current ecommerce platforms. A proof would be that can convince a reasonable human. It need not be theoretical. Feb 26 '20 at 14:24
  • @schroeder What prevents a platform that stores user details and payment methods to place a malicious order on client's behalf? I am interested in how such a solution can be handled in current systems. I am not looking for a new design. Feb 26 '20 at 14:25
  • Wait, you are changing the scenario - are you talking about consumers needing to prove or some other party? And to whom do we need to prove?
    – schroeder
    Feb 26 '20 at 14:26
1

Assuming the platform knows the user's details, this is almost certainly not possible without massively inconveniencing your users.

The easiest solution would be to just not store any user details. If the user can't place an order without entering their payment card, shipping address, and so on, then anybody can be reasonably sure that, if you have those details, the user was placing an order. However, that doesn't cover things like "what was ordered in what quantity" or prevent a malicious server from logging those details after all and using them to place another order later.

For non-repudation protection like that, you typically need some sort of attestation (on every client action) that only the client can provide. A simple example would be a digital signature (of the order details) using a private key that the client has but the server does not; the signature could be verified by anybody with the public key but couldn't be faked. This is basically the digital equivalent of requiring a customer to sign a receipt or enter their PIN, proving that they approved the transaction.

However, any kind of cryptographic scheme runs into key management problems (where does the client store the private key? Does it move between client systems following the user, and if so how? Remember that the server needs to never be allowed to use it). Additionally, for a web site, the signing would have to be done in JS, which means the server could just serve modified JS that takes the user's key and signs the order anyhow. You could tell the user that their order won't be accepted unless they use an external openpgp app to sign it (echo "I am purchasing 43 widgets" | gpg -sa) and copy-paste the signature, but it's a rare set of users who'd stand for that.

On the server side, there's no "traces" you could find that couldn't have been planted. Logs, file or database accesses, tickets in an ordering system... you control all of it, so you can fake whatever you want so long as it doesn't require knowing something that the client knows and you don't (like a private key).

The entire connection to the client is encrypted (at least, it had better be!) so even if there's a trusted third party (such as an ISP) between you and the client, they wouldn't be able to tell what was said. They could tell if there'd been no communication at all... along a particular path.

Client-side, the client could plant (or delete) any trace you might look for, and that's assuming there's anything to trace in the first place. Browser history might say what pages the user viewed, but the browser doesn't store the details of what requests it sent (unless you sit there with the dev tools open and recording) and order pages are usually dynamic anyhow. Besides, your site could contain script that quickly navigates through those pages, and then they'd be in the user's history even though no order was actually placed.

2
  • How does it work in current real-world systems like Amazon. They store user details and payment methods. What if they decide to place an order on user's behalf maliciously? Feb 26 '20 at 14:21
  • If they tried to charge my card without my express permission, I'd just contest the charge, first to Amazon and then to the credit card company if needed. Amazon doesn't want customers issuing chargebacks. Their whole business model is based on making the purchase process as low-effort as possible, which means they have basically no ability to prove you bought something. If you're issuing chargebacks fraudulently, they'll cancel and ban your account. If they're issuing charges fraudulently, that's a pretty major crime and not one they want to risk being accused of.
    – CBHacking
    Feb 26 '20 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.