Consider an ASP.NET web application [A] that makes a request to a secure web service [B] using a username and password.
The password used to authenticate to [B] is stored on [A] using “best-practices” in the web.config file and encrypted.
At some point, the unencrypted password must be present in memory on [A], right? Perhaps the web application is designed to cache the unencrypted password in a static object/string (so it only decrypts/reads from the web.config file once). Is that “statically-cached” approach worse or the same in terms of security?
Have there ever been attacks published (or is there potential for such) against ASP.NET where the attacker can access the memory of the server, potentially revealing the password?
Would it be a more secure architecture to pull the duty of communicating with [B] from [A] and assign it to a third application server [C] that is accessible by [A] but not accessible from the internet? Am I just being paranoid?
Strings in .NET can not be scheduled for garbage collection. You could read your password into a
SecureStringobject which can be forced to be garbage collected after it is no longer required.http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx