Hows does one prevent passwords and other sensitive information from appearing in an ASP.NET dump?

Question

How does one prevent passwords and other sensitive data submitted to and received from ASP.NET web pages in IIS/ASP.NET dump files?

Steps to reproduce

1. Using Visual Studio 2010, create a ASP.NET MVC 3 intranet application.
2. Configure it to use IIS 7.5.
3. Fire it up and register an account (say bob123 as the user and Pa$$w0Rd as the password. I'm assuming that the SQL Express database is created and the site is fully functional.
4. Using task manager, right click on the w3wp process and create a dump.
5. Open the dump in an editor capable of displaying its contents as hex, such as SlickEdit.
6. Search for "Pa$$0Rd" and "Pa%24%24w0Rd" in the hex dump. You should be able to find several copies of it stored as ASCII, Unicode, or encoded.

Note that it doesn't matter whether you use HTTPS because it only encrypts the communication. ASP.NET stores that data in the clear in memory or disk.

The problem

Common wisdom has it to encrypt sensitive data and not to store it in the clear. However an employee may receive a dump of an IIS/ASP.NET application and discover passwords and other confidential data of users because this information is neither encrypted, nor is memory used by ASP.NET cleared after usage.

This puts them at risk simply because they have access to it. Dump are sometimes shared with partners (such as Microsoft) to help them diagnose issues in their code. It is a necessary part of diagnosing some really complex problems in one's application.

Things I looked at

1. Use SecureString for passwords and other sensitive data. However, the ASP.NET Membership provider, along with other frameworks like WCF, often accepts passwords as System.String, which means that those copies will still be in the dump.
2. Looked to see if there is anything in the framework to clear out a copy of System.String when it is no longer being used. I couldn't find anything.
3. Investigated whether one can zero out the memory used for requests and responses once IIS is done with it, but I was unable to find anything.
4. I investigated wether one can encrypt files IIS receives (as HttpPostFile) so that they are not stored in the clear. We may receive documents that are extremely confidential and every step is made to encrypt and protect them on the server. However, someone can extract them in the clear from an IIS dump.

What I was hoping for is to tell IIS/ASP.NET that a specific request/response contains sensitive data and that IIS/ASP.NET will clear out the memory when it is done using it.

Occlude

+1 Very interesting question. I was unaware of this until now. One question I wanted to ask you is, are you hashing the passwords when using membership or are you storing them in plaintext? – Phosphene

Hashing with two salts. But that doesn't matter because the password is visible in clear text in the request to ASP.NET and thus in the dump. Also, that copy the membership provider receives is visible in the clear. And then there is also a copy of your hashed password. – Occlude

If you are not an administrator, you cannot get a dump in step 4. If you have no dump, then how can you perform the following steps? If you cannot perform the following steps, then where does your concern come from? – Gitlow

From a corporate standpoint I think this is more of an issue that you indicate. A person having administrative permissions on a server should not suddenly be in a position to gain access to confidential data in a line of business system. Using the approach outlined in the OP's question, an IT administrator could, for example, gain access to the corporate payroll system or other confidential systems. – Plummy

A more likly attack is that someone will phone up your customers prenteding to be from your support department and ask them what their password is. If you are that worried about it then I would look at a different method of authentication, hardware tokens for example (en.wikipedia.org/wiki/Hardware_token) that produce a time sensitive password. Anyway as Lex says if someone can get a dump they can probably install malitious code on your server. In other words you have already lost. – Trevatrevah

Perhaps this may explain why developers still do stupid things like store passwords in clear text or store confidential data unencrypted. They may very well assume that people can be trusted. Do you trust every administrator out there that manages web sites? Even in cloud based system? What about you're shared hosting provider? What about systems hosted in countries where laws aren't so favorable? I don't. – Occlude

Answer 1

A dump file by definition dumps all the memory the application uses at the moment it is dumped, If you were to create a filter so that certain things were excluded then you could never be sure that you had enough data to zero in on a problem.

Would you be comfortable handing over your databases / configuration settings to a third party? if not then you probably shouldn't be handing over dumpfiles either. (imho)

Hamford

However, a dump can indicate exactly where an application crashed without requiring the database or configuration. It is of tremendous value to diagnose and fix such issues. Without it, they may never be able to solve the problem. It is just a pity that recent ASP.NET requests which has already been processed, including authentication requests, are visible in the dump. – Occlude

In my experience (8 years of asp.net development), I have actually never had to "take a dump" as it were. I always either custom log all unhandled exceptions through some logger (log4net/nlog) or use something like Elmah to spot where the errors are coming from. a dump file should be your last resort, not your first... – Hamford

Andreas, you are absolutely correct. However, in my experience again where we mixed native code with managed code, dumps are often all we had when applications deadlock or terminates unexpectedly. The latter is rare in a pure managed environment. Logging only goes so far. – Occlude

fair enough, I've been spared the hassle of "going native" so far, so I haven't had the need. – Hamford

Answer 2

I know this doesn't answer the question directly but why not look at this problem differently.

You could easily put together some javascript to do the hashing client side. I would combine the password with something random such as a guid that is sent down by the server and is valid only for a single use. The data exchange would no longer contain the password and the hash could easily be compared server side. It would only be valid for the session so someone looking at the dump data couldn't use the hash to "authenticate" themselves in future.

On the file side, how are these files being uploaded? directly from a web page? There are quite a few javascript libraries that do encryption (blowfish) and I would definitely use this option when sending a sensitive file. It does have a speed penalty but you can be sure that the data is secure.

Plummy

It is certainly something to consider. However, I also have a couple of REST based web services and the confidential information accepted and sent by the service may be contained in the dump. – Occlude

You could do the same thing and encrypt that data with the javascript encryption libraries. It's far from ideal, though, because it adds a lot of overhead on both client and server. It's crazy to me that IIS keeps the SSL data in plain text within the process. – Plummy

Unfortunately my web services are being used by all sorts of clients, so it will become impractical. – Occlude