Fog Creek Software
Discussion Board




Placing Password and Account Names in Server

Hi:

I have an application that logs into the database occationally when it makes a number of select queries.

I have the account name and password stored in a properties files in my server.

The server is protected and looked after by my company's network guys.

Is it okay to have connection strings , account name and password in clear test on the server - although the server is considered secure.

Ram Dass
Monday, February 16, 2004

In general, no it's not considered secure. Most security breaches are inside jobs after all.

Microsoft's got lots of discussion on how to store this sort of information in "Writing Secure Code":

http://www.bookpool.com/.x/ehqeo5txd0/sm/0735617228

I have no idea if other OS's have similar facilities or not.

Chris Tavares
Monday, February 16, 2004

It seems to be common practice to do this with web apps (i.e. for the SQL server connection). Of course, this 'feels' wrong to me as well. If I had a copy of that book I'd be very interested in the 'right' way to do it :)

Mike Swieton
Monday, February 16, 2004

In Windows the right way to do it is to set up IIS to log on with an account that has all the permission you need, and set up SQL Server with integrated security.

Joel Spolsky
Fog Creek Software
Monday, February 16, 2004

Although if IIS is installed on your machine some might say your security is already compromised...

Since Gartner's (in)famous declaration in 2001 (http://news.com.com/2100-1001-273461.html), things have not really improved.

Joel has the right idea, but personally we prefer to substitute Apache (whether Windows or Linux) for IIS...

Phibian
Monday, February 16, 2004

We use a j2ee app server, websphere, and use its built in connection configuration.  The passwords are stored within websphere and are encrypted, but our apps just as for the 'customerDatabase'.

Koz
Monday, February 16, 2004

There's no "secure" way to do this, in the sense of not granting the privilege to an attacker.  I don't care if you're using WebSphere, IIS, Apache, whatever.  If the attacker finds an exploit that lets him run code, you're toast, plain and simple.  The best you can do in that case is slow him down by having the data in an obscure place and format.  Ironically, an "integrated" solution like the IIS approach Joel mentions may actually be *less* secure, because if I understand it correctly, the attacker won't need to find a login and password, because he'll just get access to the database without them.

So, if you want the best security, the best thing to do here is to make sure you have front ends with the least possible vulnerability to remote exploits, and then put the passwords someplace that'll take them some time and annoyance to track down.  (E.g., build a shared library that loads and decrypts the passwords, and don't leave the source code on the same machine, etc.)

Phillip J. Eby
Monday, February 16, 2004

Ideally, the database server will allow you to apply controls on a per-account basis.  In this case, you should restrict the rights of the account you are using.  Then it doesn't matter if an attacker knows the username/password - they won't be allowed to do anything beyond the functionality exposed by your app.
I think that Joel's suggestion is the right way to go.  Someone taking control of a process seems like more effort than reading data out of storage.

Brian
Tuesday, February 17, 2004

I prefer the method Joel described but another common technique is to use the Windows CryptoAPI.  This allows you to encrypt data with a key that’s tied to a Windows account.  You’d encrypt the connection string under the context of the IIS or ASP.NET account and store it under a registry key with restricted access.  This doesn’t eliminate every imaginable threat but it does greatly limit the attack surface in that just being able to read files on that machine won’t give up too much information.  A user is essentially required to be the IIS account or ASP.NET account or an admin just to get to the encrypted string and then is required to be the IIS account or ASP.NET account to decrypt it.  If someone gains that level of access to your server, the connection string is probably the least of your worries.

Do a search for CryptProtectData and aspnet_setreg (even if you aren’t using ASP.NET) for details. 

As some others have mentioned, the most important thing in this scenario is to restrict the web server to the minimal database access necessary to do what it needs to do.  For example, if you’re building an order system, the web server probably shouldn’t have permission to delete all orders. 

SomeBody
Tuesday, February 17, 2004

clear test != Secure.

Period.

Encrypt it using a secure encryption.

T.J.
Tuesday, February 17, 2004

Use the Data Protection API for storing the connection string.
You can see a complete walkthrough of an example of this is this free ondemand webcast http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032246053&Culture=en-US

Just me (Sir to you)
Thursday, February 19, 2004

*  Recent Topics

*  Fog Creek Home