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?
SecureString
is a great idea whose time has not quite arrived. It is most useful in the following scenario:
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).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.