where to save user settings in an app

[Dica]

i've got an app that needs to connect to sql server and login with a
useName/password. currently, my app saves this info in an XML file in plain
text (i.e. no encryption). everytime the app is opened, the XML file is read
and the userName/password used to establish the sql connection. is this the
normal way of doing things, or is it smarter to save these set tings
elsewhere, like the registry? if saving to XML is deemed appropriate, should
i be concerned with the plain text userName/password. i'm primarily a web
developer trying to move to desktop app development, so worrying about
saving info on the desktop is a new area for me and i'd appreciate any info
on how this is generally done.

tks in advance.

..

 

[Bob Powell [MVP]]

Saving things in the registry is not recommended anymore. An XML
configuration file is the usual way to go. For added security you can
encrypt the file using an MD5 encryption.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[john doe]

MD5 encryption isn't recommended (by Microsoft), I'd use SHA256 or 384.

This article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT11.asp
has some info, but leaves me confused as you then have the encrypted
connection string's encryption password in your source code, which even
with obfuscation is quite easy to get at. A bit of a Catch 22 it seems,
even using the DAPI.

The solution I'd use is a web service that returns the connection
string, with the web service method requiring credentials.

 

[Nicholas Paldino [.NET/C# MVP]]

Dica,

Generally speaking, I would agree with Bob's response. The only things
I would add is that this should really be contained in the app.config file
for your app.

Like Bob said, you can use encryption algorithms to encrypt the username
and password.

The only problem is where you will store the encryption key. Because it
is easy to disassemble .NET code, if you hard code the key somewhere, it
will be easy to find, and someone can circumvent the encryption easily.

Hope this helps.

 

[Guest]

I've had good luck deriving the encryption key through reflection, based on
the assembly name / version string. Additional possible benefits include the
likelihood that if the assembly has been tampered with (decompiled /
recompiled) it would become invalid.
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

Dica,

Generally speaking, I would agree with Bob's response. The only things
I would add is that this should really be contained in the app.config file
for your app.

Like Bob said, you can use encryption algorithms to encrypt the username
and password.

The only problem is where you will store the encryption key. Because it
is easy to disassemble .NET code, if you hard code the key somewhere, it
will be easy to find, and someone can circumvent the encryption easily.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

i've got an app that needs to connect to sql server and login with a
useName/password. currently, my app saves this info in an XML file in
plain
text (i.e. no encryption). everytime the app is opened, the XML file is
read
and the userName/password used to establish the sql connection. is this
the
normal way of doing things, or is it smarter to save these set tings
elsewhere, like the registry? if saving to XML is deemed appropriate,
should
i be concerned with the plain text userName/password. i'm primarily a web
developer trying to move to desktop app development, so worrying about
saving info on the desktop is a new area for me and i'd appreciate any
info
on how this is generally done.

tks in advance.

.

 

[Bob Powell [MVP]]

It almost goes without saying that a .NET application that has any sort of
software activation or licensing technology *must* be obfuscated.

Since I got the dotfuscator professional I forget whether the community
edition that comes with VS does string encryption.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

Dica,

Generally speaking, I would agree with Bob's response. The only things
I would add is that this should really be contained in the app.config file
for your app.

Like Bob said, you can use encryption algorithms to encrypt the
username and password.

The only problem is where you will store the encryption key. Because
it is easy to disassemble .NET code, if you hard code the key somewhere,
it will be easy to find, and someone can circumvent the encryption easily.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

i've got an app that needs to connect to sql server and login with a
useName/password. currently, my app saves this info in an XML file in
plain
text (i.e. no encryption). everytime the app is opened, the XML file is
read
and the userName/password used to establish the sql connection. is this
the
normal way of doing things, or is it smarter to save these set tings
elsewhere, like the registry? if saving to XML is deemed appropriate,
should
i be concerned with the plain text userName/password. i'm primarily a web
developer trying to move to desktop app development, so worrying about
saving info on the desktop is a new area for me and i'd appreciate any
info
on how this is generally done.

tks in advance.

.

 

[Guest]

Saving things in the registry is not recommended anymore. An XML
configuration file is the usual way to go. For added security you can
encrypt the file using an MD5 encryption.

Since when, and where at? The xp logo compliance doc says to use the reg
unless you've got >64k of data.

 

[Kevin Spencer]

Since when, and where at? The xp logo compliance doc says to use the reg

unless you've got >64k of data.

Let's put it this way. A .Net application can be extremely portable. All it
necessarily depends on is the .Net Framework. This allows for such niceties
as XCopy Deployment. Using the System Registry creates an external
dependency. At that point you lose that portability, and XCopy Deployment
capability.

Using the System Registry has no advantage over using an XML configuration
file. Registry values can be read as easily as config file values. Config
files can be encrypted just like Registry entries.

And finally, the System Registry stays cleaner when applications don't use
it, depend on it, leave registry entries behind when they are gone, etc.

But hey, the Registry police aren't going to come knocking on your door if
you choose to use it. And logic has never stopped anyone from doing as they
wished.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Guest]

Let's put it this way. A .Net application can be extremely portable. All it
necessarily depends on is the .Net Framework. This allows for such niceties
as XCopy Deployment. Using the System Registry creates an external
dependency. At that point you lose that portability, and XCopy Deployment
capability.

But hey, the Registry police aren't going to come knocking on your door if
you choose to use it. And logic has never stopped anyone from doing as they
wished.

Relax. Personally I think the whole dlls outside the app folder+registry
concepts were a mistake because they broke xcopy portability when moving to a
new system. I know .net did away with the former, I was unaware that the
company line had changed regarding the registry, and was wondering when it
had happened.

 

[john doe]

Even with obfuscating, the key is still in there. So it depends how
secure you want your application, and what kind of level of security
you want to protect your data with.

I know that where I work this level of security wouldn't be acceptable
with the clients we have. This is why I suggested the web service
method as the most secure means for ensuring the connection string only
goes to those people who are allowed it, and user access can be turned
off very easily.

Of course this may be "over the top" for what you're doing, so a simple
encryption of the connection string, and decryption inside the code may
well suffice.

 

[john doe]

Just out of interest, how would you unencrypt and MD5 encrypted file?
]