views:

153

answers:

4

I have a web application developed in .net 3.5, and a SQL Server database.

Current auth method is a connection string in web.config, it seems like a good idea to move the authentication details out of plain text.

So, I have two questions:

  1. Trusted Connection - The password policy here is strict, requiring frequent changes. Does this mean i'll have to update the password for the website every time it expires?

  2. Is there another/better option?

A: 

No, you won't have to keep changing the trusted connection details. You don't store the password there, so password changes won't affect you. (This is if you're using Basic Authentication, getting the users to connect to the SQL box as themselves)

But - if your application pool is running as a particular user, and that user has its password changed, you'll need to update that. You could consider having a user whose password doesn't expire for this.

Rob Farley
Thanks - unfortunately i can't log in (open ID provider is blocked) so can't upvote
nailitdown
That's odd. It recognises who you are to be able to comment, but not for upvoting (or presumably marking as an answer)?
Rob Farley
yeah, this is just a guest account that i gave the same name as my regular one... it seems questions/comments are fine but no voting
nailitdown
+1  A: 

I think putting the username/password is better simply because I don't want the user that runs my IIS server to have access to lots of databases. I would prefer to have it be focused, to where, for this application there is a user and that user has only access to this database.

You do need to be certain that your web.config file is secure, so you do need security on that.

If you want more security you could just use a dependency injection framework, and inject the compiled class that has the username/password, and just use that connection string. This class could be obfuscated, if you want some semblance of more security.

James Black
cheers james - are you implying here that by using trusted/integrated security I won't be able to assign proper permissions for the db?
nailitdown
@nailitdown - I think it is harder to lock down a database if you have one user having access to several databases, assuming you have several webapps on the same IIS server. I tend to be paranoid about things like this, probably moreso than most developers.
James Black
+2  A: 

As an alternative to trusted connection you can look at this set of articles on how to encrypt your web.config.

In brief, if you invoke from command-line

aspnet_regiis -pe "connectionStrings" -app "/SampleApplication" -prov "RsaProtectedConfigurationProvider"

section connectionStrings in the web.config of application SampleApplication from the default site will be encrypted using RSA.

elder_george
That could work, but the password policy here would require i constantly update the web.config. (I suppose i could just ignore the policy and keep a single username/password pair, but that's not really my call....)
nailitdown
A: 

Trusted connection isn't an option? A frequently changing password shouldn't be a limiting factor in your decision, since it's trusted you don't have to enter a password.

Another alternative is encrypting the connection string.

Si
Right, so as a trusted connection, I'm trusting each authenticated user who connects to the website, and then connecting to the DB with their own account... is that correct?
nailitdown
I believe you could also investigate impersonation, http://msdn.microsoft.com/en-us/library/aa292118(VS.71).aspx. Also this might be useful info: http://stackoverflow.com/questions/382383/asp-net-impersonation-and-sql-server-trusted-connection-calls
Si