Where to Store Database Connection String Info for Windows Forms Application

[Merk]

I'm looking for a safe and maintainable way to store connection string info
(connecting to SQL Server 2005 from .NET 2.0 Windows Forms client app);
things like server name or IP address and database name. I need to provide
the client application with this info for connecting to both a test SQL
Server and a production server.

I would prefer to NOT hard-code this info into the client application, and
App.Config seems rather unsafe as the users can change it with a text
editor.

What are my options?

Thanks.

 

[RobinS]

We store it in the Settings under the Project Properties. We're using
Windows security, so there are no usernames or passwords involved.

You could store two connectionstrings there (type = ConnectionString,
Scope = Application), then refer to them in your code as
My.Settings.ConnectionStringTest or something like that. (That's
what it's called in VB -- C# has different syntax.)

Robin S.

 

[RobinS]

Of course, that puts it in app.config, which is where you
didn't want to put it. Sorry about that.

Robin S.
-------------------------

 

[Bruce Wood]

I'm looking for a safe and maintainable way to store connection string info
(connecting to SQL Server 2005 from .NET 2.0 Windows Forms client app);
things like server name or IP address and database name. I need to provide
the client application with this info for connecting to both a test SQL
Server and a production server.

I would prefer to NOT hard-code this info into the client application, and
App.Config seems rather unsafe as the users can change it with a text
editor.

What are my options?

I've been looking into this same question in my spare time. One option
recommended by Microsoft is to store the connection string in
app.config, but to store it encrypted. Here is a good place to start
reading:

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

The difficulty is that all of the detailed articles I've found on
securing connection strings by encryption refer to Web applications,
not WinForms applications. There's probably a good reason for this:
encryption and decryption can work on a per-machine basis: one way you
can encrypt a string is to do so on a particular machine in such a way
that only that particular machine can decrypt it. That works great when
the only machine running your code is your IIS server. It doesn't work
at all well if you distribute your application to all and sundry.

I've yet to come across samples for a WinForms solution. Perhaps
there's a way to encrypt a string and store it in the configuration
file, then hard-code the secret portion of the key into one's
application. Hardly textbook security, but better than plaintext.

 

[Merk]

I appreciate your post. Perhaps a lazy-yet-effective way to go would be to
Base64 encode the string. That would "raise the bar enough" to satisfy my
desire to simply not have clear text in App.Config while getting around the
additional difficulties of encrypting the text. Thoughts? (and yes - I know
Base64 encoding is not the same as encryption - not even close).

Merk

 

[Bruce Wood]

I appreciate your post. Perhaps a lazy-yet-effective way to go would be to
Base64 encode the string. That would "raise the bar enough" to satisfy my
desire to simply not have clear text in App.Config while getting around the
additional difficulties of encrypting the text. Thoughts? (and yes - I know
Base64 encoding is not the same as encryption - not even close).

I had thought of that, too. That would defeat unsophisticated, curious
users. I'm hoping to raise the bar a little higher, though....

I'm reading the article to which I linked and there indeed appear to be
solutions for WinForms applications buried in there. Haven't read
enough to arrive at an answer, yet....

 

[Garry]

Did you find a satisfactory answer?

I would be grateful to know wot the details were??

Garry

 

[Bruce Wood]

Did you find a satisfactory answer?

I would be grateful to know wot the details were??

I read the pages to which I linked. It appears that the only thing
available is to store an encrypted password in the App.config file and
store the key as a literal in your program, then decrypt at runtime.
I've seen several encryption schemes suggested (all built into .NET)
but I haven't actually tried it yet.

Most other (more secure) schemes appear geared for ASP.NET / WebForms,
in which the program either runs on only one machine, or runs on a farm
over which you have control. One article had a method for dealing with
the latter case: Put the key into a container file that you then
protect using ACLs, but this of course assumes that you have
administrative privileges on the client machines and have the time and
expertise to establish and maintain a bunch of ACLs.

For applications that can be deployed to any machine (including laptops
/ tablets / etc) but for which you need to store DB user IDs and
passwords, encrypting them and then storing the key as a literal inside
the app seems the only thing available. The best you can do is make the
config file difficult to read, and so ensure that the password isn't
stored in any permanent, visible location.

No, it's not secure. In particular, someone could sift through a memory
dump of the running program and find the decrypted password (and indeed
probably the entire connection string, complete with user ID and
password) in memory. However, I see no way around this. If anyone else
has any ideas, please do post them.

 

[Shailen Sukul]

The Patterns and Practices Crytography block has a quickstart application
based on Windows Forms that might prove useful. You can get the PP Block at:
http://msdn.microsoft.com/practices/guidetype/AppBlocks/

--
With Regards
Shailen Sukul
..Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au