Securing connection between redirect from A to B domain

Question

I'm building special extension ( on domain B ) to the present e-commerce hosted on a domain A. The goal is to redirect user from A to B and back. Similar to technique where user leaves e-commerce site to the credit card payment web interface and then redirected back. Both domains are secured with SSL/TLS. User registers only on site A. Site B needs to know only users mobile number.

I came with one solution: Page A encodes users data and common secret into hash. Data and hash are posted to B. Page B receives data and hash. Then it makes its own hash out of data and common secret and compares it with hash from post request.

Flaws with this idea. Any better idea. Cookies ?

Edit: I'm trying to prevent that someone could address domain B from elsewhere. Site B provides some reservation process (mobile number as reference, sending check-in codes via sms). Someone bad could do the reservation and make our system run out of empty slots or spam us and other users - bad for buisness .

Answer 1

What you have proposed is essentially a hash-based message authentication code, or HMAC. As long as the shared secret remains secret, no one will be able to pass data to site B other than from site A.

There are some nuances to using a hash for message authentication, including the length extension attack, but depending upon the language you're using, there's probably an HMAC library function already available.

{time passes} After I've thought about this for a bit, you should include a timestamp in the data. (And so the timestamp will be passed to the HMAC function as well.) This is to prevent replay attacks, where an attacker captures a valid message (which would be hard if the connections are TLS/SSL) and sends it again later. Both servers have to have a good notion of what time it is, which you can do with NTP. You will also want to establish a timeout period, after which a message expires. To prevent a replay attack during the timeout period, you will need to cache the messages and reject duplicates.

You may want to just rely on TLS/SSL to prevent replay attacks depending on how much damage such an attack could do. If it were I, I'd include the timestamp anyway and check for anomalously "old" messages if nothing else.