How do I include a file

[Dave]

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.
--
Dave

[Jon Skeet [C# MVP]]

Dave <Da**@discussions.microsoft.com> wrote:

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.

You wouldn't use include in C/C++ either. The idea would be to read the
information from the file at *runtime*. Defining it in a different
compile-time file hardly protects it at all - the most it can do is
obfuscate it slightly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[TarteredSalmon]

I don't know why you'd want to have the connection string file on a separate
application directory, but I have done it on a different file (on the same
directory) .Here is what I have done.

I have a log in page that validates username and password from the SQL
server database (don't worry, all passwords are encrypted), so I created a
separate C# file that has a class to connect to the db. On my login page, I
created an object of the class and wala, you are ready to go.

Chao...

Now, I don't know how secure that is (I am sure some of the pundits here
will be able to answer that question), but that's my approach.
"Dave" wrote:

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.
--
Dave

[TarteredSalmon]

I don't know why you'd want to have the connection string file on a separate
application directory, but I have done it on a different file (on the same
directory) .Here is what I have done.

I have a log in page that validates username and password from the SQL
server database (don't worry, all passwords are encrypted), so I created a
separate C# file that has a class to connect to the db. On my login page, I
created an object of the class and wala, you are ready to go.

Chao...

Now, I don't know how secure that is (I am sure some of the pundits here
will be able to answer that question), but that's my approach.
"Dave" wrote:

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.
--
Dave

[Dave]

I realised it was a stupid question shortly after I posted it. In actual fact
I would think that having the connection string embedded in the middle of a
compiled .dll was pretty secure - a good deal more secure than reading it in
plain text from another file (unless the file is encrypted of course).
I suspect that all the talk about securing the connection string is aimed at
scripted HTMl files, rather than compiled code-behind files. Nevertheless
when I create a dataconnection in ASP.NET I always get a warning asking if I
want to include the password in the connection string.
This whole security thing is a bit of a maze. Anyway, thanks for responding.
--
Dave
"Jon Skeet [C# MVP]" wrote:

Dave <Da**@discussions.microsoft.com> wrote:

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.

You wouldn't use include in C/C++ either. The idea would be to read the
information from the file at *runtime*. Defining it in a different
compile-time file hardly protects it at all - the most it can do is
obfuscate it slightly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Dave]

I realised it was a stupid question shortly after I posted it. In actual fact
I would think that having the connection string embedded in the middle of a
compiled .dll was pretty secure - a good deal more secure than reading it in
plain text from another file (unless the file is encrypted of course).
I suspect that all the talk about securing the connection string is aimed at
scripted HTMl files, rather than compiled code-behind files. Nevertheless
when I create a dataconnection in ASP.NET I always get a warning asking if I
want to include the password in the connection string.
This whole security thing is a bit of a maze. Anyway, thanks for responding.
--
Dave
"Jon Skeet [C# MVP]" wrote:

Dave <Da**@discussions.microsoft.com> wrote:

Everyone keeps telling me that I should protect my database connection
information by defining the connection string in a separate file (presumably
one that is not in the application directory).
However, I can't work out how to do this as C# doesn't seem to have an
equivelant of the C/C++ #include directive.
Can someone give me the clue.

You wouldn't use include in C/C++ either. The idea would be to read the
information from the file at *runtime*. Defining it in a different
compile-time file hardly protects it at all - the most it can do is
obfuscate it slightly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Dave <Da**@discussions.microsoft.com> wrote:

I realised it was a stupid question shortly after I posted it. In actual fact
I would think that having the connection string embedded in the middle of a
compiled .dll was pretty secure - a good deal more secure than reading it in
plain text from another file (unless the file is encrypted of course).
I suspect that all the talk about securing the connection string is aimed at
scripted HTMl files, rather than compiled code-behind files. Nevertheless
when I create a dataconnection in ASP.NET I always get a warning asking if I
want to include the password in the connection string.
This whole security thing is a bit of a maze. Anyway, thanks for responding.

Just to warn you that it's really not secure at all to have a
connection string embedded in a DLL. Try it, then use Reflector
(http://www.aisto.com/roeder/dotnet/) to have a look at the assembly.

I agree it's more secure than a plain text file.

Quite how it should be secured depends on the app - it's usually not a
good idea to have a fixed password in the first place.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Dave]

Ah yes, I haven't got my head round all this reflection and obuscation stuff
yet.
Security is not a major problem for me at the moment as it's only names and
addresses, but I still don't understand how you make the database behind a
web site really secure. (I don't understand what you mean by not having a
fixed password.) What are we actually securing against? - somebody manages to
download the asp and dll files (fairly easy) and the database (more difficult
because it's not in the URL's subtree). Then they dig the password out of the
dll (I thought DLLs were just binary, but I'll take your word that it can be
done) and open the database, bingo. So, we could put the database password in
an encrytped file, but it needs to be symmetrically encrypted as the app
needs to decrypt it, and the decrypt key will have to be built into the code,
so we're back to square one.
I'm obviously missing a trick here.
--
Dave
"Jon Skeet [C# MVP]" wrote:

Dave <Da**@discussions.microsoft.com> wrote:

I realised it was a stupid question shortly after I posted it. In actual fact
I would think that having the connection string embedded in the middle of a
compiled .dll was pretty secure - a good deal more secure than reading it in
plain text from another file (unless the file is encrypted of course).
I suspect that all the talk about securing the connection string is aimed at
scripted HTMl files, rather than compiled code-behind files. Nevertheless
when I create a dataconnection in ASP.NET I always get a warning asking if I
want to include the password in the connection string.
This whole security thing is a bit of a maze. Anyway, thanks for responding.

Just to warn you that it's really not secure at all to have a
connection string embedded in a DLL. Try it, then use Reflector
(http://www.aisto.com/roeder/dotnet/) to have a look at the assembly.

I agree it's more secure than a plain text file.

Quite how it should be secured depends on the app - it's usually not a
good idea to have a fixed password in the first place.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Dave <Da**@discussions.microsoft.com> wrote:

Ah yes, I haven't got my head round all this reflection and obuscation stuff
yet.
Security is not a major problem for me at the moment as it's only names and
addresses, but I still don't understand how you make the database behind a
web site really secure. (I don't understand what you mean by not having a
fixed password.) What are we actually securing against? - somebody manages to
download the asp and dll files (fairly easy) and the database (more difficult
because it's not in the URL's subtree). Then they dig the password out of the
dll (I thought DLLs were just binary, but I'll take your word that it can be
done) and open the database, bingo. So, we could put the database password in
an encrytped file, but it needs to be symmetrically encrypted as the app
needs to decrypt it, and the decrypt key will have to be built into the code,
so we're back to square one.
I'm obviously missing a trick here.

Well, one way is to ask for the password when you install, and install
it using the Windows cryptography API which would let only the
appropriate user decrypt it. I'm afraid I don't know much about that
kind of thing, but that would be the idea.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too