Encryption of application configuration block

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have started to use the new Enterprise Library (Jan 06) and have set up a
skeleton project using the DAAB. This all seems to work fine apart from when
I come to secure the app.config file via encryption.

I have encrypted the connectionsettings block in the config file but
obviously when I come to deploy the solution to other PC's, it cannot read
the block as it doesn't have the keys to decrypt.

I understand that as far as ASP.NET goes this is ok as the data layer is
most likely going to be on the web server, but for my winforms solution I
somehow have to let the user read this encrypted block?

I have even gone as far as to store all the connection information elsewhere
in the app.config file using other encryption routines, then letting the
application read these on startup and dynamically add a new connection string
in to the DAAB. Unfortunately this doesn't work either as the app.config
appears to be cached when the application starts and you cannot get framework
2.0 to "refresh" the app.config without exiting the application and
restarting.
I even had a go at this too! (Starting to pull my hair out now!) but of
course that gives a problem for developers in that unless we have different
app.config's for development and deployment (never a good move as it's bound
to get screwed up somewhere!) then the application simply re-copies the main
app.config everytime it starts up in debug mode so you get stuck in a
viscious circle!

I really think i must be missing something somewhere as at the moment it
appears that if you need to make the app.config secure when deployed, you
cannot use the new Enterprise Libraary DAAB at all!

(I've also tried to use RSA encryption as well - but could not find out how
to export the RSA keys from a Winforms application as opposed to an ASP.NET
web site).

And help or advice would be much appreciated to help save my sanity!
 
Hi Steven,

If your trying to protect an Sql login password then instead create an Sql
login with only those permissions that are required by your application.
This way your users can see the password but can't do anything to the
database that they can't already do from your application.

Another, more secure option is to use Windows authentication and configure
access to Sql Server objects based on the current users' Windows account.
Set the connection string property "Trusted_Connection=Yes" and configure
access to Sql Server objects on a per-user basis.

If your really must encrypt your connection strings here are some links,
however note that configuration encryption is intended for applications that
reside on a server and not applications that are frequently deployed to
client machines:

Securing Connection Strings
http://msdn2.microsoft.com/en-us/library/89211k9b.aspx

Protected Configuration
http://msdn2.microsoft.com/en-us/library/53tyfkaw.aspx

- Dave Sexton
 
Thanks for the reply Dave.
If your trying to protect an Sql login password then instead create an Sql
login with only those permissions that are required by your application.
Click to expand...
This causes us a problem in that we do not want users triggering parts of
the application out of order. E.G. A user has to have rights to delete X, but
the application stops the user deleting X when Y exists. Without the business
logic in the application the user could potentially play havoc with the
system.
Another, more secure option is to use Windows authentication and configure
access to Sql Server objects based on the current users' Windows account.
Click to expand...
This would potentially help (although I still don't like potential hackers
being told exactly what database we are using on which server - I'd prefer as
little info as possible to be shown!). Unfortunately as soon as you follow
this route, the connection pooling feature of SQL becomes dramatically less
used and performance drops. We only have a single SQL login per application
and manage the user roles etc. within the application itself. This means that
connection pooling kicks in for the whole domain.
note that configuration encryption is intended for applications that
reside on a server and not applications that are frequently deployed to
client machines:
Click to expand...
Hmm ... yep, that is the problem i am having :-(

What I can't believe is that if I wish to deploy Winforms applications out
to numerous desktops securely, then the DAAB of the Enterprise Library cannot
be used? This sounds like I'm missing something - but the more I look in to
it the more I'm beginning to believe that it's impossible! :-(

I'm stuck with reverting back to the old "SQLHelper" extensions or rolling
my own but after having spent a couple of weeks converting everything across
to the new DAAB & DataFactory set up I'm reluctant to throw it all in the bin.

If it *is* impossible to do this way, does anyone know of a way that I can
dynamically change the connection string in one of the new DataFactory
CreateDatabase statements? I.E. I could point the datafactory to a dummy
alias and then override the connection string with manually decyphered
information that I could hold elsewhere? That would mean I can still use the
new datafactory routines, keep a secure app.config and deploy out to many
clients without problems.
 
Thanks for Dave's informative inputs.

Hi Steven,

Based on my understanding, your main concern is about applying encryption
protection for your client application(winform, console...)'s app.config
file and you found that the most resource on this topic is specific to
ASP.NET application, correct?

I've performed some research on the new config protection feature in .net
framework 2.0 and found that the Encryption Protection does work for both
server-side application(ASP.NET) and client applications(winform,
console...).

To protect our client application's app.config section, we can use the
following approach:

1. Use the System.Configuration.SectionInformation class's "ProtectSection"
method to protect our application's exe.config file's certain configuration
sections. And the "ProtectSection" method require us to provide a
EncryptionProvider name, we can create a custom RSA Provider(use the
aspnet_regiis.exe tool, this tool will be installed on any machine with
.net framework). use RSA key provider because it is easy for
exporting/importing when we need to deploy our application to other
machines.

For creating and exporting/importing RSA key and programmatically encrypt
sections in app.config file, you can refer to the following msdn articles:

#Walkthrough: Creating and Exporting an RSA Key Container
http://msdn2.microsoft.com/en-us/library/2w117ede.aspx

#RsaProtectedConfigurationProvider Class
http://msdn2.microsoft.com/en-us/library/system.configuration.rsaprotectedco
nfigurationprovider.aspx

Also, at development time, we need to add the following key configuration
info in machine.config so as to make our applications(which is used for
encrypting configuration file or the application whose config file will be
enrypted can find the key). for example:

========custom key info====
<configProtectedData>
<providers>
<add name="SampleProvider"
type="System.Configuration.RsaProtectedConfigurationProvider,
System.Configuration, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
processorArchitecture=MSIL"
keyContainerName="SampleKeys"
useMachineContainer="true" />
</providers>
</configProtectedData>
==================

2. At deployment time, we need to export the custom RSA key we created
ealier and import onto the target deployment machine(you can do this in the
setup program). Also, you need to make sure your client application's
app.config contains the above "custom key info" setting(so that it can find
it at the deployment machine's machine store).


Below is a simple test program demonstate programmatically encrypte the
AppSettings section of another program's exe.config file.

=====================
static void Main(string[] args)
{
string path =
@"D:\users\\workspace\ProtectConfig\ProtectConfig\bin\Debug\ProtectConfig.ex
e";


Configuration config =
ConfigurationManager.OpenExeConfiguration(path);

ConfigurationSection section =config.GetSection("appSettings");

section.SectionInformation.ForceSave= true;

section.SectionInformation.ProtectSection("SmartClientProvider");

config.Save( ConfigurationSaveMode.Full);

}
========================

I use the aspnet_regiis tool to create and manage the custom RSA key at
developing and deploying time(mentioned in the above article). In
addition, since the client application may be accessed by multiple users
with different logon users. You need to also use aspnet_regiis tool to
grant them the permission to access the key(you can consider add them in a
group and grant the group the access permission).


If you have anything unclear or any further questions, please feel free to
post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial

response from the community or a Microsoft Support Engineer within 1
business day is

acceptable. Please note that each follow up response may take approximately
2 business days

as the support professional working with you may need further investigation
to reach the

most efficient resolution. The offering is not appropriate for situations
that require

urgent, real-time or phone-based interactions or complex project analysis
and dump analysis

issues. Issues of this nature are best handled working with a dedicated
Microsoft Support

Engineer by contacting Microsoft Customer Support Services (CSS) at

http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Steven,
This would potentially help (although I still don't like potential hackers
being told exactly what database we are using on which server - I'd prefer
as
little info as possible to be shown!).
...
We only have a single SQL login per application
and manage the user roles etc. within the application itself. This means
that
connection pooling kicks in for the whole domain.
Click to expand...

Hackers that have access to your .config files would find out where your
database is regardless. Using a single SQL login makes it less secure.
 
Thanks for the reply Steven. I had actually started down this route but got
stuck on how the link between the app.config and RSA key container was
managed.
I'll have a go tomorrow with the info you have given me. Cross fingers!
 
Thanks for your response Steven,

The following configuration items is link between the "provider" we used
for encryption and the RSA key stored in machine store. On development
machine, you need to put it in machine.config. While at deployment machine,
you can just let is be in the application's app.config file.

========custom key info====
<configProtectedData>
<providers>
<add name="SampleProvider"
type="System.Configuration.RsaProtectedConfigurationProvider,
System.Configuration, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
processorArchitecture=MSIL"
keyContainerName="SampleKeys"
useMachineContainer="true" />
</providers>
</configProtectedData>
==================

Anyway, please feel free to let me know if you meet any problems or need
any other information.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello Steven,

How are doing on this, have you got it working finally? Please feel free to
post here if there is still anything we can help,

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top