Решение SecureString хорошо, но имеет внутреннее противоречие?

Question

Я видел эту тему:

Когда мне понадобится SecureString в .NET?

код есть:

SecureString password = new SecureString("password");

против

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

И я действительно понимаю преимущества второго (добавление char к char) - так что хакер не сможет отследить все символы в случайных местах в памяти (против одной строки в mem, которую он может найти).

Часть, которую я не понимаю, это та часть:

этот желтый код находится в памяти!

итак ... где выгода?

Answer 1

Второй пример кода с ToCharArray() просто демонстрирует ограниченный способ заполнения строки безопасности.Это не образец (лучшей) практики.

В теме, на которую вы ссылаетесь, содержится большинство ответов: Securestring обеспечивает частичное решение, позволяющее избежать использования простых текстовых паролей (в памяти).Не полное решение.

Но возьмите эти 2 пункта из принятого ответа:

• Элемент управления PasswordBox WPF внутренне сохраняет пароль как SecureString.
• Свойство Password для System.Diagnostics.ProcessInfo равноSecureString.

Вместе они позволят вам безопасно передать пароль процессу.

Answer 2

Пароль всегда будет незашифрован в какое-то время.Вопрос в том, «как долго?». Если вы храните его в памяти в течение полчаса в незашифрованном виде, то он, скорее всего, будет взломан, а не строкой, которая собирается через несколько секунд.