471,107 Members | 1,741 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,107 software developers and data experts.

where to save user settings in an app

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.

..
Nov 17 '05 #1
10 2269
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.

"Dica" <ge*****@hotmail.com> wrote in message
news:Ns********************@rogers.com...
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.

.

Nov 17 '05 #2
MD5 encryption isn't recommended (by Microsoft), I'd use SHA256 or 384.

This article
http://msdn.microsoft.com/library/de...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.

Nov 17 '05 #3
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]
- mv*@spam.guard.caspershouse.com

"Dica" <ge*****@hotmail.com> wrote in message
news:Ns********************@rogers.com...
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.

.

Nov 17 '05 #4
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


"Nicholas Paldino [.NET/C# MVP]" wrote:
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]
- mv*@spam.guard.caspershouse.com

"Dica" <ge*****@hotmail.com> wrote in message
news:Ns********************@rogers.com...
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.

.


Nov 17 '05 #5
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.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:%2****************@TK2MSFTNGP10.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Dica" <ge*****@hotmail.com> wrote in message
news:Ns********************@rogers.com...
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.

.


Nov 17 '05 #6


"Bob Powell [MVP]" wrote:
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.
Nov 17 '05 #7
> 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.

"Dan Neely" <Da******@discussions.microsoft.com> wrote in message
news:0E**********************************@microsof t.com...

"Bob Powell [MVP]" wrote:
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.

Nov 17 '05 #8


"Kevin Spencer" wrote:
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.
Nov 17 '05 #9
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.

Nov 17 '05 #10
Just out of interest, how would you unencrypt and MD5 encrypted file?
:o]

Nov 17 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Sam Carleton | last post: by
3 posts views Thread by Stefano | last post: by
10 posts views Thread by Paul Cheetham | last post: by
2 posts views Thread by John | last post: by
3 posts views Thread by Scott M. | last post: by
1 post views Thread by =?Utf-8?B?VGVycnk=?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.