Как лучше всего защитить конфиденциальные данные в коде?

Первый совет: никогда не храните конфиденциальные данные непосредственно в коде. Вы всегда можете перепроектировать это, как бы искусно вы ни пытались это запутать.

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

Если я правильно интерпретирую ваш сценарий, у вас есть код, который должен быть развернут в помещении некоторого клиента, и ваш код подключен к базе данных (которая, я полагаю, также находится под контролем клиента), для подключения к ней требуется пароль. Этот пароль известен этому клиенту, поэтому пытаться скрыть его от клиента довольно бесполезно. Что вы делаете, так это ограничиваете доступ к этому паролю всем, кто не должен его знать.

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

Кроме того, шифрование отдельного файла оказывается проблемой - если вы это сделаете, тогда задействован ключ, который снова должен быть каким-то образом защищен - бесконечная рекурсия на подходе :) Защитить доступ к файлу часто бывает достаточно, но если вам действительно нужно быть как можно более безопасным, тогда решение состоит в том, чтобы использовать шифрование на основе пароля для файла. Но идея здесь не в том, чтобы хранить пароль в другом месте в системе, а в виде внеполосной информации (например, в физическом хранилище) и вводить пароль при запуске приложения. Здесь тоже есть свои проблемы: для (повторного) запуска приложения требуется физическое присутствие человека, а пароль все равно можно получить из оперативной памяти машины, на которой запущено приложение. Но это, вероятно, лучшее, что вы можете сделать без специального оборудования.

Другой хорошей альтернативой шифрованию на основе паролей может быть использование «хранилищ паролей» для конкретных ОС, таких как Windows. Изолированное хранилище — это своего рода компромисс между полным отсутствием шифрования и сохранением пароля вне диапазона.

Это не ответ на шифрование, но один из способов «защитить» это - сделать все вызовы вашей базы данных через веб-службу. Затем ваши учетные данные для подключения будут храниться на вашем защищенном сервере, и клиенты будут передавать все вызовы через него.

Ничего конфиденциального не хранится в вашем распространяемом файле вообще...

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

1. Запутайте или зашифруйте значение и надейтесь на лучшее. Шифрование, конечно же, является лишь дополнительным уровнем запутывания, поскольку ключ должен быть доставлен вместе с остальными.
2. Устраните необходимость в самом ключе, используя вместо этого одностороннее шифрование. Используйте закрытый ключ для создания открытого ключа. Это можно использовать для лицензирования или проверки пароля. Вы создаете лицензии с закрытым ключом, но открытый ключ можно использовать для их проверки. Или вы используете закрытый ключ для создания пароля, который можно проверить, но нельзя отменить с помощью открытого ключа.
3. Создайте свой собственный системный механизм генерации ключей, аналогичный тому, который используется в ASP.NET. Вы можете ограничить эффект от того, что кто-то отменит шифрование/обфускацию на шаге 1, создав уникальный ключ для каждой установки или сайта.

Существует множество методов, но реальность такова, что если вы действительно хотите защитить свой код, единственным решением является использование «профессиональных» продуктов :-) не пытайтесь изобретать велосипед. Эти продукты обычно имеют опции для шифрования строк. Настоящая проблема в другом: без профессионального продукта (и даже С профессиональным продуктом) эксперт может просто поставить точку останова и посмотреть параметры, переданные библиотечному методу (например тот, который открывает соединения). Теперь... Если вы действительно хотите зашифровать строки своего кода, это довольно просто. Но будет ли это полезно? Нет.

Теперь, чтобы никто не пометил это как «не ответ», я опубликую простой код шифрования/дешифрования:

// Generate key. You do it once and save the key in the code
var encryptorForGenerateKey = Aes.Create();
encryptorForGenerateKey.BlockSize = 128;
encryptorForGenerateKey.KeySize = 128;
encryptorForGenerateKey.GenerateKey();
encryptorForGenerateKey.GenerateIV();

var key = encryptorForGenerateKey.Key;
var iv = encryptorForGenerateKey.IV;

// Encrypt: this code doesn't need to be in the program. You create a console
// program to do it
var encryptor = Aes.Create();
var encryptorTransformer = encryptorForGenerateKey.CreateEncryptor(key, iv);

string str = "Hello world";
var bytes = Encoding.UTF8.GetBytes(str);
var encrypted = encryptorTransformer.TransformFinalBlock(bytes, 0, bytes.Length);
var encryptedString = Convert.ToBase64String(encrypted);

Console.WriteLine(encryptedString);

// Decrypt: this code needs to be in the program

var decryptor = Aes.Create();
var decryptorTransformer = decryptor.CreateDecryptor(key, iv);

byte[] encrypted2 = Convert.FromBase64String(encryptedString)

var result = decryptorTransformer.TransformFinalBlock(encrypted2, 0, encrypted2.Length);

var str2 = Encoding.UTF8.GetString(result);

Этот код явно небезопасен. Любой может декомпилировать программу, добавить Console.WriteLine(str2) и перекомпилировать ее.

Конечно, вы можете зашифровать свою строку перед ее компиляцией, но ваш код иногда нуждается в этом в виде простого текста, если вы используете простой URL-адрес db или http.

В этом случае нет реальной защиты: каждый может прослушивать (точка останова) указанный метод и при вызове видеть, что происходит, не читая код. Так что нет, реальной защиты от этого нет, также используя обфускацию, в какой-то момент вы вызовете какой-то метод .NET с этой простой текстовой строкой, и каждый сможет ее прочитать.

Например, вы можете поместить dll COM или C++ для хранения зашифрованных строк. Неуправляемая dll не подлежит декомпиляции, однако опытные люди, конечно, могут понять дизассемблирование dll. И, как было сказано ранее, когда-нибудь вам понадобятся простые данные, и в этот момент нет надежной защиты.

Единственное, что вы можете сделать, это изменить архитектуру.

Например, если ваша база данных находится в сети, а ваше приложение является клиентским, вы можете подключиться с помощью веб-сервисов. Затем вы можете предоставлять только те веб-сервисы, которые действительно нужны пользователю, нет риска, что пользователь будет писать sql-запросы. Затем вы можете добавить логику защиты на сервер, а не на клиент.

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

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

Что касается хранения учетных данных, я обычно всегда храню их в файле конфигурации приложения. Если мне нужно защитить его, я использую SecureString и некоторое шифрование. И это может работать для любой информации о конфигурации, а не только для учетных данных. Здесь есть действительно хорошая статья о защите файлов конфигурации: Шифрование паролей в файле .NET app.config

Возможно, вам следует прочитать больше о шифровании файла web.config http://learn.iis.net/page.aspx/141/using-encryption-to-protect-passwords/

В противном случае вы мало что можете сделать. Хранение конфиденциальных данных в коде не вариант, поскольку любой, у кого есть инструмент Reflector, может открыть его и увидеть. Если вы хотите, чтобы код или переменные были невидимы для всех, вы должны создать веб-сервис на частном сервере, который принимает данные, преобразует их с помощью своей магии и возвращает их клиенту. Таким образом, все, что происходит между публикацией и получением данных, сохраняется в секрете.