Obsolete the SecureString type

[GrabYourPitchforks]

The SecureString type does not actually fulfill the promises it makes to developers. MSDN already disrecommends its use in new code, and there's other documentation listing some technical reasons why it can't fulfill its promises.

We've already seen customers who use this type in server applications in an effort to fulfill auditing / compliance requirements, then those customers get bitten because they fail their audits. I detailed this a little more on Twitter, including suggesting mechanisms that customers could use to meet compliance requirements.

This legacy type is a different scenario than legacy types like ArrayList (the non-generic collection type). Types like ArrayList aren't recommended for new code because there are better alternatives available, but there's no real harm in keeping those older types around for compatibility reasons. Contrast this against SecureString, where the existence of the type is causing active harm to customers who use it and subsequently fail audits.

Since the type purports to make security promises to developers, and since it cannot fulfill those promises, it should be obsoleted in the next version of .NET Core.

/cc @blowdart @bartonjs

[blowdart]

@jozefizso You thumbed down this idea, so I'm assuming you use securestring right now. Is there any chance you could expand on your objection here?

[jozefizso]

Yes, for example the PasswordBox control returns password as SecureString. This prevents the password from being written out to log files and it’s required to work with some native Win32 authentication API.

The same way you can remove MD5 hash algorithm from .NET because people are using it to insecurely store passwords.

[blowdart]

You've got about the only good example of using it right, powershell passwords being the other. MD5 at least as more legitimate uses (and is baked into the HTTP standard. Heck we can't remove 3DES because it's part of EMV).

If it was moved out of corefx and into a separate, unsuipported package, where eventually a lot of bad decisions will go and which would have a horrific name like Microsoft.Unsupported.UnsafeThings (this is why no-one lets me name stuff), where you could opt into using it, and would have to put an extra flag in your solution to maybe make people think some more, would that be helpful?

[GrabYourPitchforks]

FYI I'm not suggesting deleting the type, only obsoleting it.

Jozef, who is the adversary in your scenarios threat model? How does the use of SecureString in this particular scenario thwart the adversary?

Edit: I ask not to be argumentative, but because there might exist an opportunity to create a better type for your scenario. We might be able to craft something more narrow in scope than what SecureString was trying to accomplish, and perhaps that replacement would be better suited for your application.

[SteveL-MSFT]

In addition to logging, PowerShell also relies on this type to determine when to prompt without echo. Would it make sense to have a SensitiveString type that would also zero out memory on dispose? At least this would set some expectation, and maybe allow migration over time.

[jozefizso]

SecureString has it's obvious usages in the WinForms, WPF and PowerShell API.

Without providing any replacement nor information how to do it right and what will you do to make existing workflows like asking for passwords in console apps, password boxes, etc. and preventing passwords from leaking in places like loggin it does make sense to delete a class from .NET Framwork.

Having such a needed class in unsupported library? Ehm, no, just no.

[blowdart]

Part of the point of the issue is to gather feedback on what you use it for, however "obvious" uses doesn't help us very much. We want to know

• What your use case is? (If it's calling Win32 APIs then what Win32 APIs)
• What are you trying to protect against in that use case? What's the threat its use is countering?

We don't want to let our own biases make assumptions, we want you to be explicit please.

[yuhong]

On crash dumps: https://devblogs.microsoft.com/oldnewthing/20161104-00/?p=94645

[GrabYourPitchforks]

Related issue: GC support for zeroing the managed heap on compaction (https://github.com/dotnet/coreclr/issues/18386). The premise of that work item is to limit exposure of sensitive data in memory, regardless of whether it's in a string, array, or some other type.

[blowdart]

@jozefizso I admit I am a little confused when you mention Win32. Windows has no idea about securestrings, they're purely a .NET concept. Which APIs are you thinking of here?

[jozefizso]

Here it is: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.marshal.securestringtoglobalallocunicode

[bartonjs]

@jozefizso That's not a Win32 method, that's the marshaller method for how to pass a SecureString to a C function that takes wchar*. (Decrypt it, pass the pointer to where it's decrypted) Whatever Win32 functions are being called could work just as well with System.String, or char[].

[stevenwdv]

I'm not a professional developer yet, so I don't know if my opinion counts, but it seems weird to me that this would be obsoleted. Aren't there still benefits in using this? If you're careful you can make sure that the string has a short, predetermined, lifetime.
But maybe I'm missing something: 'obsoleted' means that it is no longer needed because there is a better alternative, right? Can you tell me what this alternative would be? (For cases where we request a password from the user.) It seems to me that using a normal string would not be better, so I guess this is not what you mean.

[bartonjs]

Aren't there still benefits in using this?

SecureString, on Windows, is useful if:

• It is properly created
  • You populate it via a one-character-at-a-time source with no read-ahead, or
  • You populate it from a native wchar* (aka C# char*) in the SecureString(char*, int) constructor.
• It is properly used
  • It is only ever used in a P/Invoke signature (or C# code that operates on the char* from the Marshaller output).

Effectively, if you've ever had the value in a System.String instance then you've lost all the "value" SecureString offers.

'obsoleted' means that it is no longer needed because there is a better alternative, right? Can you tell me what this alternative would be?

It depends on your threat model / risk concern:

• If you believe someone is actively inspecting your memory (live or hiberfil.sys):
  • The password/sensitive-material needs to never be in your memory.
    • Windows: You need a secure desktop prompt that is feeding directly into LSASS, doing work in the LSA process, and sending only the "safe" result back to your process. (No, I don't think we have code to make that happen).
    • Linux/macOS: I don't know of a solution.
• If you're concerned you'll accidentally print it in log statements:
  • Wrap a System.String in a struct with no ToString defined (or public override string ToString() => "** REDACTED **";
• If you're just mildly concerned about the password being in WER uploads or pagefiles:
  • Just use System.String, and upvote https://github.com/dotnet/coreclr/issues/18386.
• If you just like that it says "Secure" in it:
  • Just use System.String.

It seems to me that using a normal string would not be better, so I guess this is not what you mean.

It is. Just use System.String. Statistically speaking, you already had the value in a System.String (via a web request, or File.ReadAllText, or whatever), or you're at some point going to write a method like SecureStringToString, and now you've just warmed up your CPU for no real benefit.

If you're careful you can make sure that the string has a short, predetermined, lifetime.

So long as you never copied the data into byte[], char[], or System.String, sure. Most people aren't careful.

but it seems weird to me that this would be obsoleted

We actually docs-deprecated it more than 2 years ago: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md, with a big warning on MSDN/docs.microsoft.com (https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.8)

Now we're just moving it to a compile warning so more people notice.