Reputation: 4498
I'm building a payment gateway for my organization. Different apps will be able to POST data to the gateway to initialize a transaction. Some of that data will be 2 account codes, and the dollar amount.
Now my thoughts have moved to security. I'm concerned about end-users being able to change the POST information en-route to either end up paying less or having the funds deposited into the wrong account. To fix that I'm thinking of adding a hash that the app can pass.
I'm thinking each expected host will have a unique key. Along with their data they can send a hash of a random salt + their key + the 2 account codes + the dollar amount, as well as sending their random salt. On the payment gateway I can then regenerate that hash with their passed information + unique key, to see if the data has been altered.
Will this be sufficient? Are there any problems with my theory?
Upvotes: 1
Views: 1103
Reputation: 64429
This is basically what paymentserviceproviders use. The trick is that the "key" is private, so it is not one of the things you send in your post. You and the sender make the same hash, and as long as they are equal, there has been no tampering.
Another option that banks use is to make the payment separate from a post: generate a payment-request from the place that actually knows the prices (the server?) and communicate that number to your client. Then let them communicate with your payment gateway using this number instead of letting them posting any amount. There will be no tampering.
The first option is used by several payment providers I know, the second one is the one we use currently directly with our bank.
For added security of private information, let the result also contain hashes you know, so when someone (the user?) asks for the "thanks for paying" page, you can actually check it was the orgional user.
Upvotes: 1