Как защитить строки без SecureString? - PullRequest
1 голос
/ 09 апреля 2019

Вариант использования - защита строк в программировании памяти на c #.Использование класса SecureString (https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netframework-4.7.2) не рекомендуется самой Microsoft.

Мне было интересно, может ли это быть допустимой альтернативой:

  • преобразовать строку вбайтовый массив и сразу установить строку в ноль (и в конечном итоге вызвать сборщик мусора),
  • зашифровать байтовый массив с классом ProtectedMemory.

Любое предложение?

Ответы [ 3 ]

3 голосов
/ 09 апреля 2019

Я бы не сказал, что «обескуражен 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, и он все еще страдает от тех же проблем: текстовая копия зашифрованного содержимого все еще существует в памяти в течение короткого периода времени - вот в чем проблема.

3 голосов
/ 09 апреля 2019

Итак, основной вопрос, который вы задаете: «Так как Microsoft отговаривает пользователя SecureString, могу я прокрутить свой собственный?».

Что ж, кроме того факта, что ваша реализация, вероятно, будет менее защищенной, чем оригинальная версия Microsoft, она также будет по крайней мере иметь те же проблемы, поскольку они связаны не с конкретной реализацией, а с концепция.

Если вы хотите использовать эту концепцию, вы также можете использовать SecureString. Решение состоит в том, чтобы не использовать концепцию зашифрованных учетных данных в памяти ни с классами Microsoft, ни с вашим собственным домашним пивом.

3 голосов
/ 09 апреля 2019

Альтернативы классу SecureString нет.«Альтернатива», которую поощряет Microsoft, найдена здесь :

Общий подход к работе с учетными данными - избегать их и вместо этого полагаться на другие средства аутентификации, такие как сертификаты или WindowsАутентификация.

Итак, если вам действительно нужны учетные данные, а другого пути нет: в .NET Framework используйте SecureString.Для .NET Core на данный момент альтернативы нет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...