When dealing with either an oData-based application (ADO.NET Data Services), or something that otherwise publishes the PrimaryKey, or ForeignKey to the client...

Can someone explain to me be benefits of encrypting the database key when it arrives at the browser?

How would you encrypt this key? What methodologies would you use for validation?

Ideally this response would be phrased in a way that will sell a PM or executive on the benefits/drawbacks of this practice.

More Information

If you are unfamilliar with web programming, what I'm talking about is the often hidden primary key that is sent to the client (web browser, fat client, or other) and decrypted at the remote end of the HTTPS tunnel. The argument is that it is more secure to encrypt and obfuscuate the primary key (or fk for that matter) when sent to the client.


Although I haven't found any formal research per-se, I did a proof-of-concept website that applies to either a multi-tenant sites, or where there isn't enough server-side validation of the target row. I'm sure this is a security issue, but it may be too programatic in nature for this IT Security forum...

  • @makerofthings7, do you have any resources for this recommendation/argument? Any supporting links for this assumption? Because either it doesnt make much sense to me, or I'm just not understanding what you're referring to...
    – AviD
    Nov 21, 2010 at 9:39
  • I'm doing a code review for some work done in India, and in the business layer, they encrypt the database primary key before it is sent to the client, and decrypt it before it is used to actually insert a row in the server. It was wierd to me too, but now I think about it, the PK/FK should be considered untrusted data, and should be protected similar to any other client side input validation. Nov 21, 2010 at 17:56
  • Yes, your last statement is accurate - of course its untrusted data and should be validated (I assume you meant server side input validation). Both in format, and in value - e.g. if its a row to which the user is unauthorized, because he changed the value on client. I am quite familiar with web programming, but I've never heard of encrypting the PK. This just is not making much sense to me.
    – AviD
    Nov 22, 2010 at 21:44
  • P.S. I see no problem getting very programmatic in this forum too, secure coding is DEFINITELY within the purview of this SE. (In fact, it was the original topic before having other SEs merged into it :) )
    – AviD
    Nov 22, 2010 at 21:45
  • As an example: suppose there is javascript that calls this AJAX function: AddStudentToClass(string StudentPrimaryKey, string ClassPrimaryKey) and the situation where a student wants to take a 400 level class without the pre-reqs. The developer may have only displayed the classes that student may register for, but didn't do input checking on the AJAX method. In this case a student may register for something that wasn't displayed. Worse yet, they can register someone else for another class. PK encryption would help save the developer's app from a broken Business Layer. Nov 22, 2010 at 21:51

2 Answers 2


I'm going to agree with what AviD is saying in the comments.

To the original question, I don't think there are benefits to encrypting key values that are exposed by the application. To me, it sounds like an odd (and expensive, from a perf perspective) form of security by obscurity.

Security and integrity of non-secret data should be provided by solid application logic. I.E., does the current user have permission to modify the data that they're trying change? Or, does the current user have permission to add a student to this class, and is the class still open for registration?

Encrypting keys doesn't solve these problems, but in fact, can cause additional problems, like, what if a link with a valid encrypted parameter is emailed to somebody who shouldn't have access to it?

For the other example, the emailed password reset, I'm struggling to see why the encrypted key would have any significant advantages over a GUID that aren't going to be offset by the performance impact of the encryption and decryption operations.

Just my two cents of course, but I really don't see much, if any security advantage at all. I think it's just additional cost with no real benefits because most, if not all of the underlying security problems will remain and have to be solved another way regardless.

I hope this helps,


  • Thanks! I'm going to go with this reasoning as to why I'm not bringing this feature over into the new version. Nov 23, 2010 at 17:10
  • ...also if anyone in the future does see a valid use case, please add your answer. I'll be keeping an eye out. Nov 23, 2010 at 17:27

Here's a scenario.

Fred wants to hack into Barney's MyFaceIt account. He requests a password reset for his own account and gets an email with a link. https://MyFaceIt.com?reset=Fred&resetid=1234

He then requests a password reset for Barney's account. He won't see the email, but he can guess that the resetid will be 1235 or 1236 or around there.

In this situation, you might use a GUID rather than a sequentially generated key for the resetid. But there are disadvantages to GUIDs (size, index distribution...), so you might use a regular sequential id and hash/encrypt the value. That way your link becomes https://MyFaceIt.com?reset=Fred&resetid=6FFB262274EC4B50A6320CFF15763C24 It may even be https://MyFaceIt.com?reset=F6E6B9B65D7B4ED48F1B68&resetid=6FFB262274EC4B50A6320CFF15

That makes it a lot harder for Fred to guess the reset link for Barney's account.

  • Harder, but not impossible. That's what bruteforcing is for, and thats why cryptorandom identifiers should be used, NOT PKs. No real proof here, unless this is the specific case that @makerofthings7 was referring to (and if so there are other issues), this shouldnt be a PK anyway.
    – AviD
    Nov 23, 2010 at 0:31

You must log in to answer this question.

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