Securing Connection Strings

On Monday, my team at work got together and a pow-wow about security and how we can be more pro-active in developing applications.  As we went through sessions 2 & 3 from DevDays, we had a lengthly discussion on how we should proceed in securing the connection strings.  As most of you know, the OpenHack, and "best" method for securing connection strings, is by using DPAPI to encrypt it, and then store that encrypted string in a ACL'd registry key.

As this is a nice security model to follow, it doesn't work all that well in the development arena, when you have multiple machines that are hosting some version of an application.  As we discussed, we found that it would cause more of a headache when setting up a new application, as we'd have to create those ACL'd registry settings, do the encryption, etc. etc. manually.  Sure, a small application or batch could be used, but its still a pain to have to remember that you need to do it on each machine.

Another major item concerning storing the connection string in the registry, was that it breaks (what we think) the web application line.  By storing specific settings in the registry, you're starting to walk into the windows application arena.  It just doesn't make sense to us to provide that form of security when we feel its crossing that line.

Now, you may be starting to disagree with me, and thats fine.  We're still going to take an approach to encrypt the connection string in the Web.Config file, but not use DPAPI.  But - why wouldn't we want to use DPAPI, you ask?  Well, DPAPI is encryption/decryption is specific to the machine, thus decrypting a string on Machine B would not decrypt properly that was encrypted on Machine A.  (If my understanding is incorrect, please let me know - as this is a major setback for using DPAPI for us).  So, whats the big deal...well, you're going back to the model of having to manually configure each machine again, which isn't that easy to do in some environments.  So, we feel that using a specific encryption algorithm with a key is the best method, since it could be ported from machine to machine without having any problems.

I do have to agree, that if you wanted to take that extra security step by securing your encrypted connection string in a ACL'd registry key, that its a wise choice, however in most cases, its just overkill. Also, you won't ever have the option to do something like that on a shared hosting environment, so most web applications that single developers have, don't provide that form of security.

Well, I think thats all for my rant about securing connection strings, I'd love to hear your feedback.


  • Are you going to share with us how you plan to store the encryption key? For me, that is the primary motivation to use the DPAPI.

    I've developed a small "framework" for using the DPAPI in web applications, which I plan to write about on my blog soon. With a little help, it isn't so bad to work with.

  • Don't know yet, we've not come to that point.

  • I completely agree with you. Crossing that line detroys the ease in which you can port a web application. If you are using SQL Server as your database, then using windows authenticated security coupled with standard encryption of the connection string is sufficient in my opinion. Even if someone could get a hold of the connection string AND decrypt it, all they would get is the name of your SQL Server and database name.

  • Personally I think encrypting connection strings adds an unnecessary level of complexity. We use integrated security at work, so the most an attacker could get is server name and database name. I guess I could get completely paranoid and hide those too, but honestly, I just don't see the point.

  • Scott's link to draws an HTTP 404!

Comments have been disabled for this content.