Я очень удивлен, что этот вопрос не был обсужден всесторонний:
Эта статья говорит нам, как использовать windbg для дампа рабочего процесса .NET строки в памяти.
Я провел много времени, исследуя класс SecureString, который использует неуправляемые прикрепленные блоки памяти и сохраняет данные зашифрованными также. Большой материал.
Проблема входит, когда Вы используете ее значение и присваиваете его SQLConnection. Свойство ConnectionString, которое имеет Систему. Строковый тип. Что это означает? Хорошо...
Это полностью инвертирует функциональность SecureString!
Вдобавок ко всему, класс SQLConnection является ненаследуемым, я не могу даже прокрутить свое собственное со свойством SecureString вместо этого; Yay для закрытого исходного кода. Yay.
Новый уровень DAL происходит, но для новой основной версии и для такого количества пользователей это будет по крайней мере за 2 года до того, как каждый пользователь обновлен, другие могли бы остаться на старой версии неограниченно долго по любой причине.
Из-за частоты используется соединение, упорядочивание от SecureString не поможет, так как неизменные старые копии всовывают память, пока GC не приходит. Интегрированная безопасность Windows не является опцией, так как некоторые клиенты не работают над доменами и другим перемещающиеся и соединяются по сети.
Как я могу защитить строку подключения в памяти, таким образом, она не может быть просмотрена с windbg?
Если вы управляете машиной до такой степени, что можете читать память другого процесса, вы также можете заменить ссылку на класс SecureString ссылкой на строку
. У вас будет доступ к любым закрытым ключам, которые может использовать другой процесс.
Нет защиты от хакера, владеющего памятью вашего процесса. :)
Не настоящий ответ на вопрос, но все же:
Попробуйте использовать аутентификацию Windows вместо аутентификации sql.Даже если вам удастся сохранить пароль в памяти программы, пользователь сможет увидеть его с помощью сниффера трафика.
Еще одно преимущество аутентификации Windows состоит в том, что серверу sql не нужно хранить хэши паролей пользователей. С помощью проверки подлинности sql хакер может подобрать пароль из хэша или заменить его другим. На самом деле пароль можно очень легко сменить с использованием некоторых программ.
Обмен данными между процессом и сервером Sql в идеале происходит на магистрали, и если это будет скомпрометировано, то это меньшая из ваших проблем.
Поскольку это настольное приложение на стороне клиента, если вам интересно, что ваши учетные данные строки подключения могут быть доступны некоторым хакерам , это недостаток дизайна ...
Если вы подключаетесь к своему sql server с учетными данными администратора, это ваша проблема. Вы должны создать пользователя с ограничениями и использовать его в своем приложении.
Если вы боитесь раскрыть свою базу данных, вы можете получить доступ к веб-сервису из приложения. Затем этот веб-сервис получит доступ к базе данных и вернет результаты.