5

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.

Update

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
  • 50,090
  • 54
  • 250
  • 536
  • @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 '10 at 09: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. – makerofthings7 Nov 21 '10 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 '10 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 '10 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. – makerofthings7 Nov 22 '10 at 21:51
  • No, if the BL is so awfully broken anyway, how would another broken layer help? In fact, I can easily think of a number of ways this can still be bypassed on the client, if the only protection is this encryption. – AviD Nov 22 '10 at 22:19
  • The proper way to do it, is enforce authorization and business rules on the server. I would go so far as to say, thats the *only* way to do it thats worth doing. – AviD Nov 22 '10 at 22:21
  • I'm also very curious where you heard of this strange practice, did you read about / see it in someone elses system / think it up yourself? – AviD Nov 22 '10 at 22:22
  • Then you got my question... what would someone do to protect a broken BL? My guess: encrypt the PK, timestamp it, sign it so only the active user can use it. Anything else missing? – makerofthings7 Nov 22 '10 at 22:22
  • It occured to me when I was given ownership of code that was written in India. I was at first confused by the blind encryption/decryption of the PK at the data layer, but (above this comment) I dreamed up a way it *might* be useful – makerofthings7 Nov 22 '10 at 22:24

2 Answers2

7

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,

-Xander

Xander
  • 35,525
  • 27
  • 113
  • 141
1

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.

Gary
  • 884
  • 7
  • 12
  • 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 '10 at 00:31