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.
798523f1-b51b-47c8-9f05-7c9d3d3c1c09|0|.0