http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Hi, indeed integrity is missing - a good example are authorized links for Amazon S3, it let you access content with known ID (uri), but there is expiration infromation (a unique nonce will do it too) and HMAC-SHA1 signed String containing a secret key, nonce and the ID.. But you are right, sometimes better than storing everything to server side session. And thank you - a very nice example for inspiration.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment15http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment15Wed, 11 Apr 2012 13:35:09 GMTWe used a certain method to protect our image servers. We previously had build an url scheme that could specify width,height,dpi of uploaded images. Then we found out it was being abused and our servers were dying. The problem disappeared as soon as we had implemented this kind of protection. It was fun, yes :), but I would not use it for really sensitive information, though. // Ryanhttp://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment14http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment14Tue, 10 Apr 2012 11:56:46 GMTSorry, I looked over the init vectors part of your code before when I wrote my CBC remark... our solution generates new IV's for each call and passes them as part of the url.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment13http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment13Tue, 10 Apr 2012 09:05:41 GMTWe actually use this same principle to avoid ppl tampering with urls containing details about a payment. We decided to use cipher block chaining as well to patterns in the URLs for similar parameters.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment12http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment12Tue, 10 Apr 2012 09:01:54 GMTThe easiest thing would be to run the encrypted data through HMACSHA1 with a different key than the one used for encryption. You would then append that to the data being sent to the user. In C# it would look something like: byte[] signature = new HMACSHA1(key).ComputeHash(data); When the user returns be sure to validate the MAC first and reject any ciphertext that is not properly signed before ever attempting to decrypt it. You should also be aware that == will likely leak timing information during MAC verification[1]. [1] http://codahale.com/a-lesson-in-timing-attacks/http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment11http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment11Mon, 09 Apr 2012 13:51:25 GMTI think you can't tell if the data sent is actually valid because any 16 byte value should decrypt to some (random) plaintext. A cipher is just a permutation of all possible 16 byte values. People could make your app believe that there was some tenant with id "65&/$%bnsdjg" for example. Replay attack possible here. No way to revoke a guid once handed out. Can be stolen.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment10http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment10Mon, 09 Apr 2012 13:41:35 GMTI actually did this once myself, redirecting users from non-secure product page to a secured order page on another domain, in another application (long story short: keeping cert payment to the bare minimum). This is a much better solution than saving session states in a database, and it makes sure the redirect never expires (a good thing for us), but I never liked that solution. Maybe because this is basically an ASP.NET WebForms ViewState. And you want to salt this.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment9http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment9Mon, 09 Apr 2012 12:04:25 GMTAs John mentioned, you didn't include any kind of integrity check in your code. The question is: Do you want to hide the entity ID and tenant ID from the user or do you want to just prevent tampering with them? In the second case you can use a standard HMAC mechanism (compute checksum and encrypt this checksum). In the first case you can do the same and then encrypt the message as a whole again like in your code. Another problem of this approach is that it's prone to message repeat attacks. Once an attacker knows, that a specific tenant+entity id results in string X, he can always send this string X (think man in the middle attack). So it would be nice to add a changing value to the mix which you can also check.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment8http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment8Mon, 09 Apr 2012 12:01:00 GMT> Andres, This is security by obscurity, you can't decide to remove one particular value, etc. I am not sure that you have understand me, I have being talking about to store in a database a relation of entityId and tenantId with a totally random guid, for example 15 and 32 with 280b7c8b-e590-4671-8c69-ef25955eaa3f. I know that it requires more logic and it is not as functional as your design, but it is totally unbreakable and you have a great granularity if you want to allow, disallow or change one single resource access.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment7http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment7Mon, 09 Apr 2012 11:25:25 GMTThe Thing, One of the reason that I am posting this is to GET your feedback. Feel free to post about all the things broken with it.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment6http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment6Mon, 09 Apr 2012 11:13:26 GMTI think if you saw this in someone else's could we would be treated to a long blog post detailing all the things wrong with it. http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment5http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment5Mon, 09 Apr 2012 11:11:24 GMTAndres, This is security by obscurity, you can't decide to remove one particular value, etc.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment4http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment4Mon, 09 Apr 2012 10:57:55 GMTMaybe it is more secure to create a random url for each shared resource.http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment3http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment3Mon, 09 Apr 2012 10:50:49 GMTJohn, How would you use HMAC to secure things in this case?http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment2http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment2Mon, 09 Apr 2012 10:47:52 GMTBe very careful about encrypting data without providing any integrity protection. If you don't integrity protect the encrypted value, with an HMAC signature for example, then attackers can intelligently modify the encrypted value and look at indicators (error codes, timing, etc) to leak the input plaintext. This is the same problem which led to the padding oracle issue found in ASP.NET and other frameworks a few years back. http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment1http://ayende.com/153345/hiding-values-api-keys-and-other-fun-stuff#comment1Mon, 09 Apr 2012 10:45:05 GMT