17

My company runs a webshop. We work with a partner that gives discount vouchers to our customers after they buy (the vouchers can be used in other online shops) and also gives vouchers for our shop to customers of other shops. For this purpose, the partner asks us to send them some data about our customers and their respective order on our payment complete page. They want us to do this by setting some javascript variables and including a javascript from their server, which will also display an advertisement banner on our payment complete page.

I already learned that including advertisements banners bears some risk. It seems that our company already made the decision to accept this risk for this partner.

Now I am worried about one particular point. The data that the partner wants us to send also includes our customer's session id, in order to "recognize double requests" as the partner states. I think we should not sent the real session id to the partner, because with this information the partner could fake the customer's identity on our site. Therefore, I would like to send a hash of the session id instead. With this, the partner should still be able to recognize double requests without being able to fake the customer's identity.

Does this make sense? Or does the partner, by the fact that we include a javascript from their server, already have ways to do more harm than they could possible do by knowing the session id? We store the session id in an HttpOnly cookie (for the connection between our server and our customer).

If it makes sense to hash the session id, what hash function would be a good choice?

Community
  • 1
user26315
  • 173
  • 5

2 Answers2

10

Yes, what you're saying makes sense.

By setting your cookie as an HttpOnly cookie, you're mitigating the risk of your partner's JavaScript having access to the user's session ID. Since your partner insists on getting a unique identifier for your customers, I see nothing wrong with sending them a securely hashed version of the session ID.

The key point here is that you don't use the hashed version of the session ID as an identifier, so your partner won't be able to use it to impersonate your customers, but at the same time, the hashed version is unique enough for your partner to recognize your customers.

As for what to use for hashing, it doesn't matter which hashing algorithm you use, as long as its output length equals or larger than your session ID .In this case, of course, you need to use a fixed salt (a pepper) all the time because you want the same session ID to produce the same hash.

Adi
  • 43,953
  • 16
  • 137
  • 168
1

You can easily generate a different "session token" to be served for the advertiser and put that ad-token in you standard session store. In .Net, something as simple as:

void Session_Start(object sender, EventArgs e) 
{
   // assign a random GUID for the ad partner
   Session["AdToken"] = Guid.NewGuid().ToString();
}

Later, you can get the value to serve out with <%=(string)Session["AdToken"]%> (for ASPX pages).

IDisposable
  • 111
  • 2