Authoring web sites was a lot easier in the 90’s…write some static HTML, maybe some JavaScript, and you were done.  Need to update the site?  Just edit the HTML pages and upload.

In the past decade or so, web applications have made a lot of progress with interactivity and dynamic content.  Services hosted outside of the application container, such as third party web services and databases,  can provide a boatload of flexibility when designing and implementing a web site.  But, these services rarely, if ever, allow anonymous interaction…so we need to go back to our old friend, the password.

Passwords are usually stored in a configuration file along with a web application.  The configuration files are generally not made accessible with an application URL, but often connection information is stored unencrypted, which means vulnerability to security bugs that can trick the web app into displaying the configuration files.  Local access would also compromise the password, but local access almost always means that nothing is safe.

I’m in the process of authoring a new .NET app, and I’m feeling okay about the capability to encrypt sections of the web.config file (including service passwords).  This seems to be able to hide data from prying eyes using keys managed by the local security authority.  However, I haven’t yet figured out how to manage this in a deployment scenario.  Encrypting the section inherently makes it difficult to update the configuration – this now has to be done through code, because the security provider has to be invoked to decrypt and re-encrypt the configuration sections.  If the same authentication provider is used to authenticate administrators to perform these updates, then what if there is a problem with that authentication provider, and the administrators get locked out from fixing the configuration?

From a security standpoint, I have to make this work (and be usable)…I just haven’t yet figured out how.  If anyone in my legion of loyal readers has any tips, I’d be glad to hear them.