The use case is to protect strings in memory programming in c#. The use of the class SecureString (https://learn.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.7.2) is discouraged by Microsoft itself.
I was wondering if it could be a valid alternative to:
Any suggestion?
There is no alternative to the SecureString class. The 'alternative' Microsoft encourages is found here:
The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication.
So, if you really need the credentials and there is no other way: on .NET Framework, use SecureString. For .NET Core there is no alternative at the moment.
I wouldn't say it's "discouraged by Microsoft" - that's an oversimplification. The actual reasons are given in this page ( https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md ) and the argument seems to be "it isn't worth the effort to use it in .NET Core", and not that it isn't secure overall.
I contend that SecureString is secure... but only for the .NET Framework on Windows. The page I linked to is from the .NET Core project which is cross-platform - so it makes sense to discourage or disallow the use of SecureString in .NET Core - but if your project is targeting .NET Framework (which is exclusive to Windows) or is targeting .NET Core for Windows - then you're fine. The quote is below (emphasis mine):
The contents of the array is unencrypted except on .NET Framework.
BTW, SecureString can be used securely to avoid cleartext in memory if you only read secrets directly into the SecureString directly by using its Append method. This is most useful when reading passwords from the console (pseudocode):
Console.WriteLine( "Enter your password" );
SecureString password = new SecureString();
while( Char c = Console.ReadKey() != '[Enter'] ) {
password.Append( c );
}
...however if you need access to the cleartext version of the string afterwards then it's less secure (though the cleartext string would hopefully be collected by GC as a Generation 0 object).
Regarding your proposal:
- transform the string in a byte array and immediately set the string to null (and eventually call the garbage collector)
- encrypt the byte array with the class ProtectedMemory.
This is exactly how SecureString works already, and it still suffers from the same problems: the cleartext copy of the encrypted contents still exists in memory for a short period of time - that's the problem.
tl;dr: SecureString is a good and right idea. The reason Microsoft no longer recommends it is because .NET Core can't have it, because Linux doesn't support encryption.
There are two reasons you want SecureString.
The first is along the lines of the HeartBleed attack, and the reason SecureZeroMemory exists, and the reason Windows always zeros a page of memory before giving it to you: to avoid leaking information.
Bonus reading
Terminal Services keeps user passwords unencrypted in RAM.
The second, and the reason SecureString exists in .NET, is because you have no way to call SecureZeroMemory. Strings in .NET are immutable, and you don't get to control their lifetime.
So in order to solve the problem there are two elements:
When it is an array, it means you can wipe the contents. This means you can do the moral equivalent of ZeroMemory when you're done with the sensitive credit card number, bitcoin private key, password, Intel Blu-Ray Master Key: you can wipe them
That solves the problem of being completely unable to wipe a C# String
CryptProtectDataThe other, unrelated, virtue of SecureString is that the raw strings will not appear in memory dumps, virtual machine RAM snapshots, web-server logs, debugger watch windows. Or in the case of the HeartBleed attack, will not appear in uninitialized data handed out to other web-site users.
These are the two core elements that SecureString provides.
And both you can replicate. The reason .NET Core doesn't have them is not because SecureString is a bad idea, or a wasted idea, or an incomplete idea, or "doesn't deliver what it promises". Instead it's because Linux doesn't have the equivalent of CryptProtectData. And since .NET Core has to be cross-platform, they have to cater to the lowest common denominator. So they throw up their hands and say remove it.
But SecureString is just as valid as a concept as:
And anyone saying otherwise is flat out lying.
You want to use SecureString
CryptProtectData existsCryptProtectMemory existsDoes it mean that the credit card number was in plaintext in memory at some point:
No, the reason is that it has very limited use and in most cases, the string either remains in memory, or re-appears. The original string remains in memory until it's GCd. And since SecureString has no counterpart in the Win32 API (or Linux) the original string will reappear once the app tries to do anything with it. Even in the SDK only NetworkCredentials used it properly and SecureString isn't a windows concept, so once you went down to a Windows API it was converted back.
But what we have to realize is:
These are good defense-in-depth measures.
And anyone saying differently is simply wrong.
So the basic question you are asking is "since Microsoft discourages the user of SecureString, can I roll my own?".
Well, apart from the fact that your implementation will likely be less secure than Microsoft's original version, it will also at least share the same problems, because they are not with the specific implementation, but with the concept.
If you want to use the concept, you could as well use SecureString. The solution is to not use the concept of encrypted credentials in memory, neither with Microsoft's classes, nor with your own homebrew.
