A high priority for developers working with SQL data stores is to establish a way to access our Database without exposing our credentials. We want to protect our application from Hackers and hide the methods to establish a connection…
This can be a bit of a problem with the most common method of establishing a database connection for our application by including the connection information in our application configuration file. The connection may be defined by a connection string entry, or use a custom implementation to store the information.
I was reading an article from a developer demonstrating how you can use tools included with Visual Studio to encrypt your connection information in the config file, making the task of stealing your connection information more difficult for hackers. If it’s true that a majority of data intrusion is performed by internal employees or resources, then this one action has a big benefit. This implementation is specific to Microsoft products, only because it uses a canned tool they provide for the encryption prior to distribution, and decryption at run time. There is nothing wrong with that approach if you are using the Microsoft stack.
What do you do if you are not using a SQL engine for your data store? What do you do if your data access layer is not written using the Microsoft stack? One popular implementation is to write your own encryption/decryption API and include it in the necessary code. This can be done in whatever language is connecting to your database.
I have seen REST service implementation to resolve the connection string for persistence based on the system requirements. Instead of looking at a locally hosted configuration file, which may be distributed and accessible, the app calls into a service to resolve the necessary connection information. This has an advantage of resolving the connection for more than one environment of the same product, where the persistence may differ. Of course, this kind of service has the potential to be hacked. If you were to use a Web Service to resolve connection strings you can lock it down. It can define the call so that it requires secured transport, authenticated client source, and more.
It is reasonable that you may combine the last two options. Your application has limited knowledge for what it requires. That information is resolved to a web service call that is locked down to a specific set of clients. The web service could then return an encrypted value, and the application resolve the decryption in order to connect to the physical data store.
If all of your data store connectivity is inside your DMZ, your risk is highly reduced, and the implementation should be simplified.
How are you handling the management of your connection strings? Do you take the time to encrypt them? Do you encrypt them for all environments? Share your thoughts in our comments today?
Cheers,
Ben