How to avoid using System.String with Rfc2898DeriveBytes in C#

Question

I am creating a .NET core webapp in C# that takes in a user password and hashes it to be stored on a server. I'm using Rfc2898DeriveBytes along with a randomly generated salt. I've read, however, that I should avoid using strings in the entire process since strings cannot be removed from memory. I know that .NET core has a PasswordBox that keeps the password as a SecureString, but SecureStrings cannot be converted to a byte array to be passed to Rfc2898DeriveBytes's constructor without a great deal of shenanigans.

Since the webapp is only going to run on my server, can I just convert the SecureString back to a string as soon as it has been passed into my webapp? If an attacker manages to access the server's RAM to search for an undeleted string, there's probably very little I can do to protect anything to begin with.

If I should still go through with using SecureStrings, what are the best practices for hashing it to be stored?

Answer 1

Using SecureString correctly is difficult, and protects against a threat surface that is unlikely for most use cases. As you say, if an attacker can read your memory, you have other problems. I would advise to use normal strings instead of SecureString, unless you are worried by attackers carrying liquid nitrogen with physical access to your server.

If you really want to use SecureStrings, you should P/Invoke the Windows crypto API so that you have control over memory. I have an example in my blog post Comparing secure strings in .NET.

Answer 2

The .NET Core team specifically recommends against using SecureString for new development. See the SecureString documentation:

We don't recommend that you use the SecureString class for new development. For more information, see SecureString shouldn't be used on GitHub.

as well as the team's reasoning on GitHub:

Motivation

• The purpose of SecureString is to avoid having secrets stored in the process memory as plain text.
• However, even on Windows, SecureString doesn't exist as an OS concept.
  • It just makes the window getting the plain text shorter; it doesn't fully prevent it as .NET still has to convert the string to a plain text representation.
  • The benefit is that the plain text representation doesn't hang around as an instance of System.String -- the lifetime of the native buffer is shorter.
• The contents of the array is unencrypted except on .NET Framework.
  • In .NET Framework, the contents of the internal char array is encrypted. .NET doesn't support encryption in all environments, either due to missing APIs or key management issues.