473,326 Members | 2,012 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

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

Connection String in .config file - Security Concerns

Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should key
be kept.

Thank you

Jan 25 '06 #1
14 1986
Check out the DPAPI

http://msdn.microsoft.com/library/de...SecNetHT07.asp

Or you can build a data access layer that is behind a firewall.

_Randal

Jan 25 '06 #2
It really depends on how ultra secure you need to be.

You can argue that if someone gained access to your machine to the point
that they can look at your web.config, then it is too late anyway, and that
person already has enough access to inflict all sorts of damage.

Now, beyond that, it is about how much harder you want to make it for the
person who breached your security. Certainly reading it from a config file
is a lot less work then decompiling a dll (or many dll's), and searching
through it looking for the one spot where the encryption key is. Then the
person has to write a little program or something to decrypt using your
encryption key. Now you have added a lot more work, and so this hacker may
not actualy go and do all this.

"WebMatrix" <We*******@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.com...
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows
security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to
breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should
key
be kept.

Thank you

Jan 25 '06 #3
Well, security is definitely a concern. First, do you want to trust Windows
in its security, however, it is not like they have had any significant
vulnerabilities. ;-)

Second, if anyone was to gain physical access to the machine they would be
able to see the credentials.

In short, best practices says that credentials should not be stored in
plaintext.

There are two ways of going about securing you databases.

1) Encryption is a possibility. You are correct about the problem with
storing a key. That kind of defines the chicken-and-the-egg problem in that
in order to secure secrets you must define new secrets. One way around this
would be to use the DPAPI that is part of Windows
(http://msdn.microsoft.com/library/de...ecNetHT07.asp).
This does not require that you use a key because it derives the key from
information on the system.
2) You can use trusted connections between SqlServer and your website.
This means that you do not have to store the username and password. You can
simply tell IIS to trust the webserver account.
"WebMatrix" <We*******@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.com...
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows
security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to
breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should
key
be kept.

Thank you

Jan 25 '06 #4
Everybody is right. These files are not served, so it really boils down to
"How secure do I need to be". In ASP.NET 1.1 there is a utility for this
exact purpose:

http://support.microsoft.com/Default.aspx?kbid=329290

In ASP.NET 2.0, the feature is built into the Framwork.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"WebMatrix" wrote:
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should key
be kept.

Thank you

Jan 25 '06 #5
This only works with certain elements in the config file. I do not think it
works with any arbitrary content. This has been a complaint of mine for
some time about this utility.

-----
When you apply the hotfix that is described in Microsoft Knowledge Base
article 329250 (see "References"), you can use encrypted data that is stored
in the registry instead of plain text in the following configuration
sections: . <identity userName= password= />
. <processModel userName= password= />
. <sessionState stateConnectionString= sqlConnectionString= />

-----
"Peter Bromberg [C# MVP]" <pb*******@yahoo.nospammin.com> wrote in message
news:83**********************************@microsof t.com...
Everybody is right. These files are not served, so it really boils down
to
"How secure do I need to be". In ASP.NET 1.1 there is a utility for this
exact purpose:

http://support.microsoft.com/Default.aspx?kbid=329290

In ASP.NET 2.0, the feature is built into the Framwork.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"WebMatrix" wrote:
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows
security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere.
Hard
coding it in the code would mean that someone could easily disassemble
web
app .dll file and get that key, if someone already was smart enough to
breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should
key
be kept.

Thank you

Jan 25 '06 #6
In reality, there is a security concern. There is never a solution in
security, which is why everything is called a "deterrent".

If you set IIS up properly, and assuming that there are no security
flaws in IIS which would serve up the config file (ha!), you still have to
worry about internal threats. If someone has access to the machine, then
they can easily look in the web config file for the username and password
that accesses the database.

You can encrypt the string, but then you have to protect the key.
However, encryption is a deterrent, because no one is going to try and brute
force the decryption. Here is a blog entry regarding encrypting the
connection string in ASP.NET:

http://weblogs.asp.net/owscott/archi...29/421063.aspx

However, I think that neither of these is a good solution. Personally,
I think that you should be using windows authentication to access your DB
server (SQL Server does this, I dont know about others). Of course, I don't
recommend that you allow the ASPNET user to access the SQL Server. Rather,
if you are using windows identities, and you are impersonating, I would use
a trusted connection.

Even if not using windows identities, I would place my data operations
in a class derived from ServicedComponent that ASPNET can access, and then
have the ServicedComponent (COM+) run under a single user account that has
acceess to the database. You can set the connection string as the
construction string for the ServicedComponent, and use a trusted connection.
Then, only administrators can access the components on the machine, and see
the connection string, and if they did, they wouldn't know the credentials
to the database.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"WebMatrix" <We*******@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.com...
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows
security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to
breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should
key
be kept.

Thank you

Jan 25 '06 #7
You can encrypt several sections (including connection strings) using the
in-built encryption methods in ASP.NET 2.0;

http://msdn.microsoft.com/library/de...aght000005.asp

This protects the file from plain text (reading) attacks. *however*, if
somebody can write a simple .NET web-page, it can *directly* read the
unencrypted values (the encryption is completely transparent to an ASP.NET
web-page running in the correct account). For this reason, using this
approach I would still not recommend storing passwords (trusted logins being
preferable). And because the connection-string section in ASP.NET is well
supported, it is also very easy to ask "what connection strings have you
got?" rather than needing to know anything in advance. This can be done with
a simple ashx dumped into the root of the web application - in less than a
page you can attempt to connect to all the servers listed and try to get
their catalogues...

IMO any DPAPI wrapper is, in its way, susceptible to the same type of
attack - as long as they can get code to run in an account that has access
to the read-keys (i.e. the web-server's account), it can be hacked. If
somebody can be bothered.

But as sombody else observed, if they can get this far you're already in
trouble...

Marc

Jan 25 '06 #8
THe problem with using trusted connections to SQL Server is that connection
pools don't work with trusted connections. Also, trusted connections only
work when the SQL Server is on the same machine as IIS.

The rest of what everyone has said is definitely correct, in the
circumstances where those solutions (or deterrents) work best.

If you're able to use the Enterprise Library, it has relatively secure
encryption capability for the connection string.

In the project I am currently working on, Enterprise Library is not an
option (which is fine with me - I'm not a big fan of it anyway) and because
the IIS machines are separate from the database (the database is DB2 on a
mainframe) and the IIS servers are, by policy, not allowed to access the
registry.

As a result, I just wrote a simple encryption/decryption utility based on my
article at
http://www.dalepreston.com/Blog/2005...is-simple.html.

The problem with this, and all solutions that are not DPAPI based, is that
the server has to be able to access the encrypted data and the decryption
key. If someone can get to the server to find the web.config file in the
first place, they will have access to the encrypted connection string and the
key to decrypt it.

The best you can hope to do, and you should do it, is to encrypt the string,
hide the key as best you can using Windows security, either in the file
system or in the registry, or even in your app, and hope that is enough
deterrent for someone who penetrates your physical and file system security
otherwise.

Or, put IIS and SQL Server on the same box, forfit connection pooling, and
use Windows Integrated Authentication.
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Nicholas Paldino [.NET/C# MVP]" wrote:
In reality, there is a security concern. There is never a solution in
security, which is why everything is called a "deterrent".

If you set IIS up properly, and assuming that there are no security
flaws in IIS which would serve up the config file (ha!), you still have to
worry about internal threats. If someone has access to the machine, then
they can easily look in the web config file for the username and password
that accesses the database.

You can encrypt the string, but then you have to protect the key.
However, encryption is a deterrent, because no one is going to try and brute
force the decryption. Here is a blog entry regarding encrypting the
connection string in ASP.NET:

http://weblogs.asp.net/owscott/archi...29/421063.aspx

However, I think that neither of these is a good solution. Personally,
I think that you should be using windows authentication to access your DB
server (SQL Server does this, I dont know about others). Of course, I don't
recommend that you allow the ASPNET user to access the SQL Server. Rather,
if you are using windows identities, and you are impersonating, I would use
a trusted connection.

Even if not using windows identities, I would place my data operations
in a class derived from ServicedComponent that ASPNET can access, and then
have the ServicedComponent (COM+) run under a single user account that has
acceess to the database. You can set the connection string as the
construction string for the ServicedComponent, and use a trusted connection.
Then, only administrators can access the components on the machine, and see
the connection string, and if they did, they wouldn't know the credentials
to the database.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"WebMatrix" <We*******@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.com...
Hello,

I have developed a web application that connects to 2 different database
servers. The connection strings with db username + password are stored in
web.config file.
After a code review, one developer suggested that it's a security flaw;
therefore connection strings should be kept somewhere else or encrypted.
My argument is that web.config file is protected by IIS and Windows
security
which is the case. And another argument is that encryption would probably
require a key or cipher which also would have to be stored somewhere. Hard
coding it in the code would mean that someone could easily disassemble web
app .dll file and get that key, if someone already was smart enough to
breach
IIS and Windows security.

My questions to you:
1. Any real life concerns keeping connection strings in .config files
2. Other locations where connection strings can be kept securely
3. If you do recommend encryption, what encryption methods, Where should
key
be kept.

Thank you


Jan 26 '06 #9
> Also, trusted connections only work when the SQL Server is on the same
machine as IIS


No; trusted connections using a domain account will work anwhere within that
domain; if you use machine (not domain) accounts, you can mirror the account
(same name and password) on 2 machines trusted connections can work.

Marc
Jan 26 '06 #10

"Marc Gravell" <mg******@rm.com> wrote in message
news:eC**************@TK2MSFTNGP09.phx.gbl...
|> Also, trusted connections only work when the SQL Server is on the same
| > machine as IIS
|
| No; trusted connections using a domain account will work anwhere within
that
| domain; if you use machine (not domain) accounts, you can mirror the
account
| (same name and password) on 2 machines trusted connections can work.
|
| Marc
|
|

Very true, and connection pooling works also as long as they use the same
credentials to connect to the same Server instance.

Note that, "trusted connections" aren't used to authenticate when the client
and the server (here SQL server) are running on the same box. Trusted
connections are used by the 'local' LSA to connect to the 'remote' LSA, when
both client and server are on the same box the LSA is the same for the
client and the server and no authentication handshake is needed.

Willy.

Jan 26 '06 #11
IIS will not pass the users credentials to SQL Server on another machine even
if you set your application for impersonation. The only credentials it will
pass are those for the service account that your IIS application is running
under.

--
Dale Preston
MCAD C#
MCSE, MCDBA
"Marc Gravell" wrote:
Also, trusted connections only work when the SQL Server is on the same
machine as IIS


No; trusted connections using a domain account will work anwhere within that
domain; if you use machine (not domain) accounts, you can mirror the account
(same name and password) on 2 machines trusted connections can work.

Marc

Jan 27 '06 #12
From
http://msdn.microsoft.com/library/de...eSecurity.asp:

"There are some drawbacks to using integrated security, most of which you
can overcome. Because integrated security requires a Windows account, it
defeats connection pooling if you impersonate each authenticated principal
using an individual Windows account."
--
Dale Preston
MCAD C#
MCSE, MCDBA
"Willy Denoyette [MVP]" wrote:

"Marc Gravell" <mg******@rm.com> wrote in message
news:eC**************@TK2MSFTNGP09.phx.gbl...
|> Also, trusted connections only work when the SQL Server is on the same
| > machine as IIS
|
| No; trusted connections using a domain account will work anwhere within
that
| domain; if you use machine (not domain) accounts, you can mirror the
account
| (same name and password) on 2 machines trusted connections can work.
|
| Marc
|
|

Very true, and connection pooling works also as long as they use the same
credentials to connect to the same Server instance.

Note that, "trusted connections" aren't used to authenticate when the client
and the server (here SQL server) are running on the same box. Trusted
connections are used by the 'local' LSA to connect to the 'remote' LSA, when
both client and server are on the same box the LSA is the same for the
client and the server and no authentication handshake is needed.

Willy.

Jan 27 '06 #13
That's why I said, the "same user credentials", right?
Connection pooling is used when an "application" creates "multiple
connections" with the 'same' SQL Server using the 'same' windows
credentials. That means that you have as many pools as there are credentials
used to connect to the same SQL server.

The point is that you should use the same credentials when connecting to the
same instance of the server to take advantage of connection pooling, that
is, you shouldn't impersonate the client in IIS to connect to external
resources (which would require Kerberos delegation anyway).
Willy.

"Dale" <da******@nospam.nospam> wrote in message
news:7F**********************************@microsof t.com...
| From
|
http://msdn.microsoft.com/library/de...eSecurity.asp:
|
| "There are some drawbacks to using integrated security, most of which you
| can overcome. Because integrated security requires a Windows account, it
| defeats connection pooling if you impersonate each authenticated principal
| using an individual Windows account."
|
|
| --
| Dale Preston
| MCAD C#
| MCSE, MCDBA
|
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > "Marc Gravell" <mg******@rm.com> wrote in message
| > news:eC**************@TK2MSFTNGP09.phx.gbl...
| > |> Also, trusted connections only work when the SQL Server is on the
same
| > | > machine as IIS
| > |
| > | No; trusted connections using a domain account will work anwhere
within
| > that
| > | domain; if you use machine (not domain) accounts, you can mirror the
| > account
| > | (same name and password) on 2 machines trusted connections can work.
| > |
| > | Marc
| > |
| > |
| >
| > Very true, and connection pooling works also as long as they use the
same
| > credentials to connect to the same Server instance.
| >
| > Note that, "trusted connections" aren't used to authenticate when the
client
| > and the server (here SQL server) are running on the same box. Trusted
| > connections are used by the 'local' LSA to connect to the 'remote' LSA,
when
| > both client and server are on the same box the LSA is the same for the
| > client and the server and no authentication handshake is needed.
| >
| > Willy.
| >
| >
| >
| >
Jan 27 '06 #14
Ahh... No, I'm talking about a "Trusted Subsystem" model, where-by the
authentication (at the boundary to the web-server) is *not* the same as the
identity used to connect to remote resources. This would generally be a
single (least-priveleged) account, with access to exactly the servers etc
that it needs. This can be done using either app pools or serviced
components (the first being simpler to implement and manage, but potentially
more open to abuse if somebody can infect your web-server)

http://msdn.microsoft.com/library/de...aght000008.asp

The title sounds promising: "How To: Connect to SQL Server Using Windows
Authentication in ASP.NET 2.0"

Marc
Jan 27 '06 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Shyam | last post by:
Hi, I wanted some advice on the following. All the users who log in to the system are created in the SQL Server. As I am not keen to store any user information on the web.config file for...
4
by: Charlie | last post by:
Hi: I'm storing my dB connection in web.config file. Since it will be easily read by opening file, what is a good way to secure it? Thanks, Charlie
12
by: Charlie | last post by:
Hi: My host will not allow me use a trusted connection or make registry setting, so I'm stuck trying find a way to hide connection string which will be stored in web.config file. If I encrypt...
0
by: dbuchanan | last post by:
While trying to use a config file to provide my connection string I get a System.ArgumentException with the following message; "Format of the initialization string does not conform to specification...
6
by: Bala Nagarajan | last post by:
Hello, I am using Oracle 9i in my application and facing a problem with the connection string. In the datasource attribute of the connection string i had to specify an entry in "tnsnames.ora"...
14
by: WebMatrix | last post by:
Hello, I have developed a web application that connects to 2 different database servers. The connection strings with db username + password are stored in web.config file. After a code review,...
7
by: Jim Butler | last post by:
I have this error that is happening on all of our web servers (production included). It basically started occurring once we loaded 2005 sql client tools, asp.net 2.0 (and all related prerequistes)...
2
by: SAL | last post by:
Hello, I am working with Framework 1.1 and Microsoft Enterprise Library 2005. I've used the Enterprise Library Configuration utility to create my app.config & dataConfiguration.config files. ...
3
by: Ted | last post by:
In WSAT, I get the following error when trying to set up my provider: Could not establish a connection to the database. If you have not yet created the SQL Server database, exit the Web Site...
8
by: Brett | last post by:
I wrote an ASP.NET application that queries a SQL Server database (on a different box from the web server) and displays the result in a GridView. The datasource for the GridView is a SQLDataSource....
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

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.