I've seen a lot of people asking questions about how to encrypt sections of their web.config, so I thought I'd create a small tool to help make this easier. It's pretty easy to use, you just have to click one link. Can I get a few people willing to test this and provide feedback? Joel Thoms DiscountASP.NET http://www.DiscountASP.NET Post Edited (Joel Thoms) : 2/27/2007 4:09:16 AM GMT
Update... Worked like a charm. I could smack ya however...My own fault though...Couldn't find ddlProviders_Load Then I realized you had a section of the code behind collapsed. lol Sometimes those little tics in VS are hard to notice... I tested it both ways and was impressed with the formatting it left behind. Expected it to make a mess when it unencrypted the strings but it did a great job. The one and only neededchange I could spot is the Page Title, it needs one. Other than that a simple security measure might be nice; simple hard-coded password toload the page. btw, you made nice use of the asp:Literal controls. With all the blog battles lately over when to use them, when to never use a label, ie carumba... http://www.haacked.com/archive/2007/02/15/ASP.NET_Tip_-_Use_The_Label_Control_Correctly.aspx
I will test it for you bro but this is a bit confusing because it was my understanding that DASP does not allow encrypted web.config's; Can we get an official Yeah or Nay?
It's not that we don't allow people to encrypt their web.config. It's that nobody has figured out an easy way to do this. Most examples use DpapiProtectionConfigurationProvider, which requires your aspnet user to have access to folders and directories that don't exist. I believe it may be possible to use this in DASP in the future, but it'll require modifications to our system. (that's if it's even possible). You should be able to use both RsaProtectedConfigurationProvider and DataProtectionConfigurationProvider without any problems on DASP. You can read the pros and cons about each of these at http://aspnet.4guysfromrolla.com/articles/021506-1.aspx I may provide some additional details on the different configuration providers, but I have to do more reading on them myself Joel Thoms DiscountASP.NET http://www.DiscountASP.NET
If you want any changes to the script, lemme know. Or if you make any changes, send them my way Joel Thoms DiscountASP.NET http://www.DiscountASP.NET
Will do bro. It was my miss-understanding aboutencryption not being allowed. Bruce had simply mentioned that it is not supported: http://community.discountasp.net/default.aspx?f=24&m=12371 I'm at the age where what I see and what I really see are two different things. lol btw, didn't you see Scott's posts about "super simple" config encryption methods? http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx Search his blog, he brought it up at least 7 times last year. There are a few videos out there from the team, was part of the ASP.NET 2.0 Tricks/Tips series last year.
According to the ASP.NET team this was first offered by popular request from the general public, of Web developers. It would be foolish to post web.config attack methods publicly, here, but... One method is when a community site allows more than one user FTP access. You are correct however, even a great tool like this needs at least one additional security measure. I've been thinking of a GUI key, not related to the machine, that could be used for each case. If I come up with something I'll let Joel know, but he may already be working on that.
Am I the only one that questions the usefulness of web.config encryption? I mean, ok, so now we can encrypt web.config and assuming someone is smart enough to get our web.config, they can't read it. But, if that someone was already a DASP customer (and if they really wanted your goods, it don't cost much to become one) then they could likely just upload your web.config to their own space and unencrypt it since it'll probably use the same machine-specific stuff, right? I suppose there's no guarantee they would be on the same machine though, but... If they got your web.config in the first place, wouldn't they be technically savvy enough (and at that point have enough access) to just put their own "unencrypt me" page on your site and hit it?!? I always got the impression this encryption stuff was just put in to shut up the security weenies who shit a brick when they see any kind of password "in the clear", since this'll give them the illusion of security even though any half-way intelligent attacker could circumvent it - IF they could get to your web.config in the first place. The best security measure seems to be don't let them get that file - once they have enough access to even get that file,there's really nothing that's going to stop em... By the way, this is in no way an attach on Joel's implementation - it's sweet - I just wonder why MS put this in at all... Post Edited (Jamie) : 2/26/2007 2:48:44 AM GMT
...Wow; I can't believe you made all those changes, awesome. The way you check for the keyContainerName when the page loads is spiffy. These new methodsgive any ASP.NET 2.0 developer several options to work with. Well done bro.
I have updated the code. Re-download from original post. Joel Thoms DiscountASP.NET http://www.DiscountASP.NET
Joel, How do I run the aspnet_regiss commands on the external server? I need to run the commands: aspnet_regiss -pi "SharedKeys" keys.xml aspnet_regiis -pa "ShareKeys" "ASPNET" BTW this is my current web.conf file, do I need to put avalue in the cspProviderName? <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <configProtectedData defaultProvider="MyProtectedConfigurationProvider"> <providers> <add name="MyProtectedConfigurationProvider" type="System.Configuration.RsaProtectedConfigurationProvider" cspProviderName="" useMachineContainer="true" useOAEP="false" keyContainerName="SharedKeys" /> </providers> </configProtectedData> etc....
The commands you are running and your web.config look different than the instructions I provided. You should viewmy code examples andinstructionsI provide in the zip file, it should become more clear. Joel Thoms DiscountASP.NET http://www.DiscountASP.NET
Peter Bromberg posted something that needs to be added to this thread: http://www.eggheadcafe.com/tutorials/aspnet/8b53894c-a889-4914-8c46-122980cc44ae/simple-xor-encryption.aspx Solution: http://www.eggheadcafe.com/fileupload/-1724526549_SimpleXOREncryption.zip He makes a good point about discretion in an Intranet environment... I've been through that and agree, many managers will request this.
Joel, thanks for your example, great job. And as always, thanks to DASP for their superior developer support. Sincerely superior... My post here is a bit past the thread's due date so, perhaps the thread is dead by now... Anyway, I understand the RSA encryption methods here and they work well and for me that is enough. I had tried to use DPAPI before but as you well point out, that does not work for many reasons. However, you indicate that using DataProtectionConfigurationProvider (default Windows encryption) should work and you have a sample for that provider on your code. While this will work on the developer's box, I don't see how this is any different than DPAPI, in other words, that cannot possibly work on the DASP server. I've tried your code and mine for that matter on DataProtectionConfigurationProvider and it does not work. The problem is the same as DPAPI - priviledged access to locations or API's. I believe this happens because under the default identity (ASPNET process) DataProtectionConfiguration has no valid access to the API. Your code uses this provider by first retrieving the IDENTITY entry in web config. That would work of course but you would need to mention that that IDENTITY needs to be explicitly entered into web.config as either an impersonation (which is not desirable inmany cases) or as the actual user (DASP User Name) which is also a form of impersonation and may not be desirable for some. In other words, under the default ASPNET worker proces identity (say WEBxxx\aspnet_xxxxx), DataProtectionConfigurationProvider will not work on the server though it will on the developer box. Unless, IDENTITY impersonation is provided through web.config (which your code sample looks for). Just a note of clarification for those that may go for the default provider programmatically. The only good way to do this is through the RSA method DASP has provided. Any other methods will simply not work at this time unless one is willing to concede additional things, such us identity impersonation in web.config... Unless, I am missing the obvious which I might be... thanks Madvox
Madvox, This post is actually a little bit outdated. See these KB for moreupdated information http://kb.discountasp.net/article.aspx?id=10478 http://kb.discountasp.net/article.aspx?id=10477 Bruce DiscountASP.NET www.DiscountASP.NET
