Royi Namir
Royi Namir

Reputation: 148684

SecureString Solution is fine but has inner contradiction?

I saw this thread :

When would I need a SecureString in .NET?

the code there is :

SecureString password = new SecureString("password");

vs

SecureString pass = new SecureString();
foreach (char c in "password".ToCharArray())
    pass.AppendChar(c);

And I do understand the benefits of the second one ( adding char by char) - so that the hacker will not be able to track all chars which in random places in memory ( vs one string in mem which he can find).

The Part which I dont understnad is that part : enter image description here

that yellow code is deferentially in memory !

so ... where is the benefit ?

Upvotes: 3

Views: 268

Answers (2)

Henk Holterman
Henk Holterman

Reputation: 273581

The 2nd code sample with ToCharArray() just demonstrates the restricted way for filling a securestring. It is not a sample of a (best) practice.

The thread you link to provides most of the answers: Securestring provides a partial solution to avoiding plain-text passwords (in memory). Not a complete solution.

But take these 2 points from the accepted answer:

  • WPF's PasswordBox control keeps the password as a SecureString internally.
  • System.Diagnostics.ProcessInfo's Password property is a SecureString.

Together they would allow you to safely transfer a password to a process.

Upvotes: 3

Olivier Jacot-Descombes
Olivier Jacot-Descombes

Reputation: 112632

The password will always be unencrypted at some time. The question is, “for how long time?” If you keep it unencrypted for half an hour in memory it is more likely to be hacked than a string that is garbage collected after a few seconds.

Upvotes: 1

Related Questions