views:

222

answers:

3

I have been tasked with securing the connection string in an classic ASP application and I'm wondering if I should just bite the bullet and upgrade the whole application to ASP.NET, or if there is a simple fix.

Currently the application connects to an ODBC datasource with a connection string like this:

DSN=Mydb;uid=myuser;pwd=mypassword;DATABASE=mydb

My question is, is it possible to encrypt this password somehow, or to remove ODBC from the equation?

+2  A: 

You can run the web application under a domain user and use integrated security instead of spelling out the user id and password in the connection string.

Otávio Décio
+1, as long as the database driver supports integrated security (which most do).
devstuff
Running a web application as a domain user poses a set of other challenges: making sure that this user has the same privileges as the default ASP app identity; maintaining user life cycle (e.g. changing password in IIS when it expires; having to create a separate domain account for DB connection, since using regular user account may not be a good idea); now allowing any other Web app running under this site to connect to the database server; etc. Depending on your environment and requirements, these may not be a big deal, but you at least need to be aware of these issues.
Alek Davis
+1  A: 

Rather than ODBC, you can consider OLEDB. I generally recommend the latter, (with possible exceptions for example when one need/like the indirection provided by the ODBC configuration which allows switching dbs without changing the application's configuration or source code).

EDIT: in reading the question quickly, I came to he idea that you were using MySQL (all these "my" in the conn. string snippet...), and hence the following my not apply if another database is in use...

However, as you seek to not supply the password in the connection string, it may not be possible to use OLEDB, as MySQL documentation on this type of connection doesn't seem to allow alternate authentications but accountid/password.

You may therefore need/like the ability to call ODBC with integrated security and have the MySQL accountid/password stored at the level of the ODBC configuration for this source. In this fashion the password is not referenced at the application level (but still found in the ODBC config...).
With ODBC the connection string key=value pair for using integrated security is

"Integrated Security=SSPI" 
which I believe is equivalent to 
"Trusted_Connection=yes"

A useful reference for connection strings is aptly named www.connectionstrings.com

mjv
A: 

Another alternative is to encrypt the connection string using some algorithm (or using some component like RSADLL) and then decrypt the connectionstring in the app.

Do not forget to provide a servicing page to allow administrators to create a encrypted connection string.

Eduardo Molteni