Я бы не сказал, что «обескуражен Microsoft» - это упрощение. Фактические причины приведены на этой странице (https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md), и аргумент выглядит так: «Не стоит усилий использовать его в .NET Core», а не то, что он не является безопасным в целом.
Я утверждаю, что SecureString
является безопасным ... но только для .NET Framework в Windows. Страница, на которую я ссылаюсь, принадлежит проекту .NET Core, который является кроссплатформенным, поэтому имеет смысл не рекомендовать или запрещать использование SecureString
в .NET Core, но если ваш проект нацелен на .NET Framework (который является эксклюзивным на Windows) или нацеливается на .NET Core для Windows - тогда все в порядке. Цитата ниже (выделено мое):
Содержимое массива в незашифрованном виде за исключением .NET Framework .
Кстати, SecureString
можно безопасно использовать, чтобы избежать открытого текста в памяти, если вы только читаете секреты непосредственно в SecureString
напрямую, используя метод Append
. Это наиболее полезно при чтении паролей с консоли (псевдокод):
Console.WriteLine( "Enter your password" );
SecureString password = new SecureString();
while( Char c = Console.ReadKey() != '[Enter'] ) {
password.Append( c );
}
... однако, если впоследствии вам понадобится доступ к версии открытого текста строки, тогда она менее безопасна (хотя, как мы надеемся, строка открытого текста будет собрана GC как объект поколения 0).
По вашему предложению:
- преобразовать строку в байтовый массив и сразу установить строку в null (и в конечном итоге вызвать сборщик мусора)
- зашифровывает массив байтов с помощью класса ProtectedMemory.
Именно так уже работает SecureString, и он все еще страдает от тех же проблем: текстовая копия зашифрованного содержимого все еще существует в памяти в течение короткого периода времени - вот в чем проблема.