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

Question

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.

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

The only time I flag the missing use of SecureString when performing secure code reviews, are in instances where the data may be encrypted by the application and reused.

For instance, when a website backend needs to communicate with a third party or another internal resource that requires credentials. Since these can't be hashed, I would use the SecureString when needing to build the request (which should be over TLS as well).

Another alternative is to use the Windows Data Protection API if possible.

Note that the purpose of SecureString is to keep the contents in memory for as short a time as possible.

View more solutions

Comments

[Mathieu Le Tiec]

I've had this question too, and I was thinking using Ajax to send one character at a time to the server. Haven't finished my proof-of-concept yet, though.

[Ashif Nataliya]

you said "it makes little sense". Shouldn't it be "it makes no sense" in case of reading passsword from user? because it does not serve its purpose in asp.net. SecureString claims that it prevent revelation of information. But does it 100% prevent revelation in asp.net? My question here [stackoverflow.com/questions/23775907/… is marked as dubplicate but I don't understand. Can you please help me understand?

[Frédéric Hamidi]

@Akie, you may be reading too much in the terminology. "Makes no sense" is harsh enough that I used a softer alternative, but the point is the same: if security-sensitive data comes from an ASP.NET from, using SecureString to protect it won't bring you anything (or, in a softer tone, "won't bring you much").

[smith willy]

The problem isn't that the value is a String, it is that it is in the memory unencrypted, so a memory dump would reveal byte arrays just as much as strings. Since the hypothetical attacker would be using a server memory dump (say sent to a vendor for troubleshooting), such an attacker would be working at the byte level anyhow.

[Matt Borja]

"It's nonsense" (more concise) :D