Is there any benefit to using SecureString in ASP.NET?

If I understand correctly, this is for keeping plain text out of memory, so that the app is secure against esoteric attacks on memory, the garbage heap, or memory paged to disk. The SecureString is fed unmanaged bytes and consumed one unmanaged byte at at time--then the string is erased from memory. (Correct me if I way off!)

In ASP.NET, the secret is collected in a webform, which post back in HTTPS. But then the Request object turns all the request values from the form into name value pairs and puts them in a collection, e.g. Request["TxtPassword"]-- so even before I can get the string, it's already been written insecurely to memory. Worse, if I was using a control, then the unsecure representation will have more managed strings in the property of the TextBox.

To do anything with this SecureString I need an API that takes unmanaged strings--so it seems I can't use the secure string for a stored proc parameter or much else.

Am I doing this wrong or is it a fool's errand to try to use SecureString and not leak copies of the unsecured string into managed memory?

Switching to OAuth or Windows auth isn't an option.

As you correctly deduced, and others already mentioned, it makes little sense to use SecureString to store security-sensitive data that comes from an ASP.NET form, because that data is already present in memory in plain text.

There are other scenarios, however, where the use of SecureString is recommended, because the sensitive data is created by the program itself and should not remain in memory after it's done working with it. For instance, creating a SharePoint site programmatically, or transferring authentication credentials from one system to another.

Back in the good old days, it was easier to ensure that the lifetime of sensitive data was as short as possible. It could be allocated on the stack and cleared as soon as the program was done using it:

char secret[512];
generate_secret(secret, sizeof(secret));
do_something_with(secret);
memset(secret, 0, sizeof(secret));
// Secret data is now gone.

Such an approach is not possible with managed strings, though, mainly because:

• They're not allocated on the stack,
• They're immutable, so they cannot be cleared,
• They're not disposable, so there is no guarantee about the time when the GC will free the data. It might even never be freed, depending on memory conditions.

SecureString tries to solve that problem by being mutable and disposable, which allows one to write:

using (SecureString secret = new SecureString()) {
    GenerateSecret(secret);
    secret.MakeReadOnly();
    DoSomethingWith(secret);
}
// Secret data is now gone.

SecureString is best used for allocating network credentials for direct calls between systems. It's a given in the web arena that if the credential came in through the web that it's in plaintext somewhere, but if you have to send that credential back out through a standard credential call (ftp, directory services, etc), then using SecureString does not hurt as a passing method. While you're correct that the string is already on your server system in plain text, you can at least reduce the footprint between systems. If you're only using this password locally, then I would agree that SecureString is probably not terribly necessary.

Good security habits, though, are never really a waste of time.

I think you have the basics of it. SecureString is designed from the point of view of being on the Client Side. So for a WPF/Winforms app (and maybe Silverlight, can't remember if it is in there) it is worth tons while for a server side app, not as much due to not being the first to handle the string.