.NET security of objects in memory

Question

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?

Answer 1

Strings in .NET can not be scheduled for garbage collection. You could read your password into a SecureString object 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

Answer 2

First off, an encrypted web.config section really isn't that secure. Quite frankly if they can get to the point of reading the web.config file then they are only a very minor step away from being able to have the app divulge the entire unencrypted contents of it.

Yes, the unencrypted section of the web.config is present in memory. Neither approach you define really has an impact on the level of security offered.

Yes, there have been attacks where memory dumps have happened. There have also been attacks where the contents of supposedly protected files, such as the web.config, have been divulged. You do keep up with your patches.. right?

Further IF the attacker has the capability to upload a single page to your site then that page will have ALL of the same access rights (including decrypting your web.config) and exposing that data.

"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?"

Um.. no. If A is cracked then the number of layers you put between A and B is immaterial.

You need to ensure that B is not accessible via the Internet. Further, your firewall should make sure that the ONLY thing that can talk to B is A. The communication between A and B should be encrypted on the wire.

Also, B shouldn't implicitly trust A. In other words A should send the appropriate USER credentials to B every time a secured transaction is taking place. And B should be responsible for verifying that those credentials are authorized to take the requested action.

Let's assume B is a database server and A is a web site that people log into. Every single time A sends a query to B it should include the end user's credentials. B should then check authentication and authorization of those credentials to make sure that this User is allowed to take the requested action. Of course, this requires A to NOT have direct access to run queries on B.. but that's a whole different topic.

---

Answer 3

If this was an application sitting on a user's machine, I'd be rather worried about it. For a web based server, I really don't think you should expect malicious users to have access to your memory. It's probably already too late for you if they're at that point.

Answer 4

If an attacker can read/write arbitrary memory to the ASP.NET process, there is absolutely nothing you can do to protect against this. Anything that you can do, he can patch away. Even if you did a 3rd server C, he could just patch 'A' to send the password to a malicious service instead.