What is the best way to store connection string in .NET DLLs?

The application my team is currently developing has a DLL that is used to perform all database access. The application can not use a trusted connection because the database is behind a firewall and the domain server is not. So it appears that the connection string needs to have a DB username and password. The DLL currently has the database connection string hard coded, but I don't want to do this when we launch as the assembly can be disassembled and the username and password would be right there in the open.

One of the requirements is that the password needs to be changed once every few months, so we would need to roll that out to our internal user base.

Is there a way to store the password encrypted in such a way we can easily distribute to the entire user base without storing it in the assembly?

Thanks in advance!

UPDATE: Thanks to everyone who's answered. I'll try to answer some of the questions back to me... The data DLL is used by both ASP.NET WebForms and VB.NET WinForms. I understand that Applications can have their own config files, but I haven't seen anything on config files for DLLs. Unfortunately, I can't get to the Jon Galloway post at work so I can't judge if that will work. From a development standpoint, we don't want to use web services inhouse, but may be providing them to third parties sometime next year. I don't think impersonation will work because we can't authenticate the user through the firewall. As a user (or former user) can be an attacker, we're keeping it from everyone!

From stackoverflow proudgeekdad

• I'm not certain, but I believe you can put it in a config file and encrypt the config file.

  Update: See Jon Galloway's post here.

  From Adam V

• @proudgeekdad:

  Is this an ASP.NET app or a windows forms app running on multiple machines?

  If it's an ASP.NET app then just encrypt the connection strings section of your web.config.

  If it's a client app running on multiple machines, instead of storing the connection string locally, consider using a web service or some other kind of secure mechanism to store it centrally. This would facilitate easier updates in the future and you're not storing the connection string locally.

  Just some thoughts.

  Updated: @lassevk

  "Storing the connection string on a server, and obtaining it through a web connection sounds good, until you realize that you need security on that web connection as well, otherwise an attacker could just as well impersonate your program and talk to the web connection."

  Security on the web service was implicit. Depending on the type of deployment there are a numerous options...for example client side certificates.

  From Kev

• I hate to say this but as soon as you put something on a client machine, security for that data goes out the window.

  If your program is going to decrypt that string, you need to assume that an attacker can do the same. Attaching a debugger to your program would be one way.

  Storing the connection string on a server, and obtaining it through a web connection sounds good, until you realize that you need security on that web connection as well, otherwise an attacker could just as well impersonate your program and talk to the web connection.

  Let me ask a question. Who are you hiding the connection string from? The user or an attacker? And if the user, why?

  From Lasse V. Karlsen

• There are some other idea's also. You can always use impersonation. Also, you can use the Enterprise Library's (Common Library).

  <section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  <enterpriseLibrary.ConfigurationSource selectedSource="Common">
  <sources>
    <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
      filePath="Config\Exception.config" />
  </sources>
  

  From Brian Childress

• .NET supports encryption on config values like this. You could leave it in a config file, but encrypted.

  From EndangeredMassa

• You want to be able to distribute the DLL with all of the setup information being in a configurable place, but the fact is you can't have one of the handy-dandy .NET config files for a DLL unless you do something custom.

  Maybe you need to rethink what responsibility your DLL should have. Would it be possible, or make sense to require that the connection string be passed in by the user of your library? Does it really make sense that your DLL reads a config file?

  From Brad Barker

• Just assume that the bad guys WILL get the credentials out of your config file. This means that they'd be able to login to your database and do whatever that user is capable of. So just make sure that user can't do anything bad like access the tables directly. Make that user only capable of executing certain stored procedures and you'll be in better shape. This is one place that sprocs shine.

  Matt Blaine : I always try to limit the SQL login for web apps I've worked on in as many ways as possible.
  From Webjedi

• Several options: 1. Store in web.config and encrypt. 2. Store in dll and obfuscate (dotfuscator). 3. Store one in web.config (encrypted of course) and rest in the database (if u have to use multiple and encryption/decryption becomes a pain).

  From