I'm developing an ASP.NET MVC 5 website, which a user can select some filters, based on those fillers the server process a result, and the user can make a order and pay for it.

In my Order table i store the filters(5 columns), the Id(PK), and i need to store a OrderId in a cookie to track it, i know that is a bad practice to expose and store the PK on the client side so i create another column called OrderId. This order id must be unique too, and friendly read (so a GUID is discard here), i thought to get the DateTime("yyyyMMddhhmmssffff") and concat with other filter to make this Id, but i think that is a weak option because an attacker could find the pattern easily.

What is the option that I have to deal with this situation? May I hash this OrderID before save the cookie? And about saving the plain code on DB? The cookie validation is 24 hours.

  • And about people like me who don't accept cookies at all ? Or that let the browser delete them after user close it? Cookies are a thing of the past...move foward
    – Freedo
    Jun 2, 2015 at 7:45
  • Well, for users like you, the only problem is that you make a research and dont order it on the same time, next time that you go to the site you will need to make the order again.
    – gog
    Jun 2, 2015 at 12:17

2 Answers 2


Depending on the sensitivity of the data, I would suggesting the following items, arranged from least secure to most secure.

Do Nothing: Based on the contents of your question, I'd probably choose this option. A lookup filter isn't associated to a user (apparently) and probably doesn't expose anything particularly interesting. You could even expose the PK directly without too much worry, unless those filters could expose sensitive data. I know plenty of systems that use other means of protecting filters (and all other data), most notably using an actual session ID so the filter can only be seen by users authorized to see it.

Randomize PK: Make the PK a random number instead of auto-number. This keeps people from guessing PKs by counting back and forth. This makes it harder to find a valid filter. I would use this if the filter doesn't contain any sensitive data at all; make it non-trivial for an attacker to find a random filter. I would use a large random number space, such as 64-, 128-, or 256-bit numbers. Use this if you simply want to avoid people "sniffing" your database for interesting values.

Sign PK: Attach a nonce or MAC to each PK, so that the nonce and PK together are needed to retrieve the value. This prevents casual modification of the PK on the client. Validate that the MAC or nonce matches the expected value. This should deter casual hackers, especially if the data is particularly uninteresting and doesn't contain personal information.

Encrypt PK: Simply encrypt the cookie before sending it. This is the first recommendation in the list that suggests that the PK isn't directly sent to the client, and I would only use this method for personally identifying information, or if exposure of the filter would result in potential fraud. I would also combine this step with signing and randomization for a robust solution.

  • Do you mean hash with a salt? Jun 1, 2015 at 20:07
  • Depending on the size of the PK, a hash might be more appropriate. For large PKs, there's a small chance of hash collision. Either way, the salt is more significant to prevent simple pre-computed style attacks, since the PK is still a fairly small space to search in.
    – phyrfox
    Jun 1, 2015 at 20:14
  • 1
    You state "encrypt the cookie with salt". Did you mean "hash the cookie with salt"? Jun 1, 2015 at 20:15
  • Hashes are one way functions. How would you retrieve the PK from a hash?
    – phyrfox
    Jun 1, 2015 at 20:24
  • 1
    @NeilSmithline You're right... I got myself confused. I'll amend.
    – phyrfox
    Jun 1, 2015 at 22:17

You never need to use cookies.

Put the order ID in the query string (rewrite the page links to include it).

On the server side validate the request by storing the IP of the client. Do not allow computers with different IPs to access the same order.

  • There are cases where a user's session can legitimately be active while the user is switching IP addresses (TOR, mobile in motion, etc.) so while this suggestion is very useful, it has some serious limitations for some use cases.
    – schroeder
    Jun 2, 2015 at 4:31
  • I dont see a point to avoid the cookie in that situation, will need to trust in the IP, and make a new request to the database.
    – gog
    Jun 2, 2015 at 12:19
  • @ggui Besides the advantage of supporting users that have cookies turned off, the OP has specifically says he wants to avoid storing data on the client side for security reasons. Using a query string embedding avoids storing data on the client machine. Jun 2, 2015 at 12:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .