Question

I know there is the SecureString class, but for most scenarios I don’t think it’s really useful.

For example, let’s say I have a client/server system. The server doesn’t need an application made by me, it could be even SQL Server without integrated authentication. When the user enters his password on a form in the client app, it’s stored in clear text in memory, so, while I can use a SecureString to read it, I can’t really see the point on doing so. Sure, it can reduce the attack surface, but not much… Even if I did, when the user hits ‘OK’, a plain text string must be generated, even if I just need to compute a hash from it.

So, is there anyway to avoid the password strings to float around until the GC decides to reclaim the memory? Even then, would the memory get erased before it’s used again?

Answer 1

SecureString is a great idea whose time has not quite arrived. It is most useful in the following scenario:

1. Your presentation layer password box grabs each keypress individually and stuffs them into a SecureString one at a time. The class exposes several mutating methods specifically designed to facilitate this. For example, WPF supports this (via the PasswordBox.SecurePassword control property).
2. Your authentication API accepts passwords of type SecureString natively.

If either of these is untrue, then you are pretty much wasting your time, since at some point in the code path you will be forced to unpack the SecureString into a String.

The safest way to authenticate a user is always to avoid handling username/password credentials altogether. You could use Windows authentication, InfoCards, OpenID, etc instead.