Securing the cache

Feb 2, 2009 at 1:59 PM
Is there a way to have the shared cache only available to certian applications on certian networks? I have a dev, qa and prod and don't want someone to insert or change production cache with dev or qa.

Feb 2, 2009 at 7:13 PM
hi michael,

thanks for your post.

currently we are not able to prevent network ranges to connect.

Mar 2, 2009 at 11:38 PM
One thing we do is append the assembly version to all keys used - that prevents the scenario he mentioned. But you still have the issue that if you want to secure the server so that only certain groups can access it, similar to SQL server you pretty much have no recourse other than encrypting everything that goes in which would negate much of the performance benefit. Would be extremely nice if you could at least limit access to only domain authenticated users somehow, I'm still trying to figure out how to do this before IT security here gets wind of this and makes us get rid of it.
Mar 3, 2009 at 8:02 AM
Or you can secure your network/servers using firewall hardware/software...
Mar 3, 2009 at 3:41 PM
Edited Mar 3, 2009 at 3:44 PM
Please explain what you mean. Our scenario is that we have internal users only, so the outside world is completely out of the equation. The situation I am talking about is a rogue user inside the company that doesn't have access to the SQL servers, apps, etc. because he is a contractor, guest, etc. That person can see the cache server and if he is able to determine the cache key to use and do the deserialization (or just download this open source client!) he can get all that data he would normally be restricted to. How would you solve that?
Mar 3, 2009 at 7:45 PM
Edited Mar 3, 2009 at 7:46 PM

how about handling it with encryption? something like this could be managed very fast (
would that case handle your problems?

lets say you can configure a certain key which will be used for encrypting data.

regards, roni
Mar 4, 2009 at 12:07 AM
Here is a thought Roni:

I know you have added methods for DataContract serialization. Have you given any thought to switching the SharedCache transport protocol to WCF, rather than sockets? This would add support for all of these security items, as well as adding support of duplex channel operations (such as event callbacks, etc).  I realize this is a huge change, but I am just curious, since I am in the process of migrating some of my WSE web services over to WCF, and have been impressed by the technology.
Mar 4, 2009 at 1:47 AM
The whole point of the cache is performance. If I am encrypting the entire contents of the cache (instead of authenticating users once on connection like SQL Server, Windows, etc.) that is going to have an impact on performance. I will do some tests though and see what that impact is, maybe post a codeproject article on it.
Mar 4, 2009 at 1:49 AM
Edited Mar 4, 2009 at 1:50 AM
Ah, posting that message, I just had a thought. I could do something like how SSL works (without encrypting the traffic since SQL server, etc. doesn't encrypt the traffic itself without some additional work) and have some kind of handshake in that in order to make a request you have to have first submitted and exchanged some public/private key pairs. That will involve some changes to the code but I'll look into that as well. We use this on .NET 2.0 projects so WCF isn't an options for us yet.
Mar 4, 2009 at 8:19 AM
Well, if you have a webapplication deployed on servers A and B and shared cache on servers C and D, you can make sure that only servers A and B are allowed to connect on that specific port on servers C and D.

I'm not a network admin, so I don't know all the details (depends a bit on your network infrastucture), but the same has been done to e.g. database servers...
Mar 4, 2009 at 9:21 AM
In our scenario we are using the caching for desktop apps, web apps and services which are all over the company and isn't limited to a single group of servers on a network segment, DMZ, etc. Really we need the equivalent of SQL Server Windows authentication or even SQL Server authentication for the cache server.
Mar 5, 2009 at 12:54 AM
I went the route of encrypting all content and only took a 14% performance hit. Here are the numbers for a set of tests I've been using to get a ball park idea on cache performance.

Pre-cache performance: 70 seconds
After shared cache: 44 seconds
After encryption: 50 seconds

So it isn't too bad. I did have to make changes to the actual source code since the serialization is tucked away inside the provider, i.e. there is no Get call that returns a byte array, though there is an add call that does.
Mar 5, 2009 at 6:15 PM
can you share the code? maybe i'm able to add it to

regards and thanks, roni    
Mar 5, 2009 at 8:17 PM
I uploaded it as a patch. It's implemented as an interface, that way the encryption details can be done in the project using the shared cache instead of internally, but I also included my quick implementation to prove the concept. You may want to clean up how the provider is set and there may be other instances where it needs to be called (MultiAdd/Get) this is just a proof of concept.
Mar 15, 2009 at 7:40 PM
in my change set from today: 26072 i have takeover a part of your solution and I plan to provide this over client configuration within the release
Mar 15, 2009 at 7:40 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.