Блог

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

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

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

Есть предложения?

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

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

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

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

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

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

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

tl; dr: SecureString — хорошая и правильная идея. Причина, по которой Microsoft больше не рекомендует это, заключается в том, что .NET Core не может этого иметь, потому что Linux не поддерживает шифрование.

Короткий ответ

• Используйте массив символов
• Зашифруйте его

Длинный ответ

Есть две причины, по которым вам нужна SecureString.

Первый из них похож на атаку HeartBleed, и причина, по которой существует SecureZeroMemory, и причина, по которой Windows всегда обнуляет страницу памяти, прежде чем предоставить ее вам: чтобы избежать утечки информации.

Бонусное чтение

Службы терминалов хранят пароли пользователей в незашифрованном виде в оперативной памяти.

• https://pentestlab.blog/2021/05/24/dumping-rdp-credentials/

Вторая и причина, по которой SecureString существует в .NET, заключается в том, что у вас нет способа вызвать SecureZeroMemory . Строки в .NET неизменяемы, и вы не можете контролировать их время жизни.

Итак, для решения проблемы есть два элемента:

1. Вы можете переключиться на массив символов.

Когда это массив, это означает, что вы можете стереть содержимое. Это означает, что вы можете сделать моральный эквивалент ZeroMemory того, когда вы закончите с конфиденциальным номером кредитной карты, закрытым ключом bitcoin, паролем, мастер-ключом Intel Blu-Ray: вы можете стереть их

Это решает проблему полной неспособности стереть строку C #

2. Шифрование с помощью CryptProtectData

Другим, не связанным с SecureString преимуществом является то, что необработанные строки не будут отображаться в дампах памяти, моментальных снимках оперативной памяти виртуальной машины, журналах веб-сервера, окнах просмотра отладчика. Или, в случае атаки HeartBleed, не будет отображаться в неинициализированных данных, передаваемых другим пользователям веб-сайта.

Это два основных элемента, которые предоставляет SecureString.

И оба вы можете реплицировать. Причина .В NET Core их нет не потому, что SecureString — плохая идея, или бесполезная идея, или неполная идея, или «не выполняет то, что обещает». Вместо этого это потому, что в Linux нет эквивалента CryptProtectData . И поскольку .NET Core должен быть кроссплатформенным, они должны соответствовать наименьшему общему знаменателю. Поэтому они разводят руками и говорят, удалите это.

Но SecureString так же действителен как концепция, как:

• ZeroMemory
• SecureZeroMemory
• Windows обнуляет страницу оперативной памяти, прежде чем передать ее вашему процессу
• почему, когда вы устанавливаете filevaliddata, Windows обнуляет содержимое файла

И любой, кто говорит иначе, откровенно лжет.

Напоминание — вы хотите использовать SecureString

Вы хотите использовать SecureString

• по той же причине существует SecureZeroMemory
• по той же причине существует RtlSecureZeroMemory
• по той же причине CryptProtectData существует
• по той же причине CryptProtectMemory существует
• по той же причине Windows zero удаляет страницу памяти, прежде чем передать ее вашему процессу
• по той же причине Windows обнуляет содержимое файла, прежде чем передавать его вашему процессу
• по той же причине HeartBleed пришлось исправить
• за то же самое, из-за чего у Facebook возникли проблемы
• по той же причине iOS стирает ваш ключ из памяти при блокировке устройства
• по той же причине аудит VeraCrypt обнаружил, что они не стирают нажатия клавиш из памяти
• по той же причине вы можете зашифровать свой файл подкачки
• по той же причине вы можете стереть файл подкачки при завершении работы
• по той же причине LastPass, 1Pass, KneePass, Windows Credential Manager шифруют пароли

Означает ли это, что номер кредитной карты в какой-то момент был в виде открытого текста в памяти:

Нет, причина в том, что он имеет очень ограниченное использование, и в большинстве случаев строка либо остается в памяти, либо появляется снова. Исходная строка остается в памяти до тех пор, пока она не будет GCd. И поскольку SecureString не имеет аналога в Win32 API (или Linux), исходная строка появится снова, как только приложение попытается что-либо с ней сделать. Даже в SDK только NetworkCredentials правильно его использовали, а SecureString не является концепцией Windows, поэтому, как только вы перешли к Windows API, он был преобразован обратно.

• Да, в какой-то момент номер кредитной карты был в виде открытого текста в памяти.
• Да, пароль пользователя bitlocker в какой-то момент был в памяти.
• Да, PIN-код пользователя iOS в какой-то момент был в памяти.
• Да, закрытый ключ биткойна в какой-то момент был в памяти.
• Да, данные в зашифрованном файле подкачки в какой-то момент были незашифрованы в ОЗУ.

Но мы должны понимать, что:

• Это не значит, что вы не должны стирать его из памяти
• это не значит, что вы не должны препятствовать его появлению в файле журнала
• это не значит, что вы не должны препятствовать его появлению в файле подкачки
• это не значит, что вы не должны предотвращать его появление в файле аварийного дампа
• это не значит, что вы не должны препятствовать его появлению в окне просмотра
• это не значит, что вы не должны препятствовать его появлению в моментальном снимке

Это хорошие меры углубленной защиты.

И любой, кто говорит иначе, просто неправ.