Как я могу скрыть конфиденциальные данные в моем проекте с открытым исходным кодом?

У меня есть проект с открытым исходным кодом, который загружает файлы в DropBox среди нескольких файловых хостов. Прямо сейчас я делаю скриншот для DropBox. Чтобы использовать их API, я должен жестко закодировать СЕКРЕТНЫЙ КЛЮЧ, предоставленный мне для аутентификации OAuth. Но я боюсь, что ключ не будет секретным, если он будет виден всем.

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

Я нашел этот вопрос без ответа, который имеет ту же проблему, что и мой.

Но я хотел бы знать, как в целом скрыть конфиденциальные данные в проекте с открытым исходным кодом.

У меня есть одна идея.

• Есть заполнитель в исходном коде, например "<SECRET KEY HERE>", и заполните его только при сборке двоичного кода для выпуска? (Тьфу!)

Любая приличная идея?

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

Заполнители в коде (жестко закодированные значения)

Заполнители в коде - как было предложено - что наиболее разумно и проще всего сделать в динамических языках программирования, так как код легко изменить (без необходимости компиляции). Я видел много проектов с открытым исходным кодом, таких как MediaWiki с этим LocalSettings.php.

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

Конфигурационные текстовые файлы

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

В вашем случае вы можете создать key.confтекстовый файл с фактическим ключом, позволить программе использовать этот файл и позволить ему игнорировать управление версиями. Для удобства вы можете проверить key.conf.exampleтекстовый файл с помощью фиктивной клавиши и проверить это. Убедитесь, что ваша программа / приложение делает полезное сообщение об ошибке для пользователя, чтобы добавить фактический ключ в правильный файл.

Некоторые языки программирования имеют API, которые предоставляют это автоматически, например:

• В Java Свойства API , Preferences API , Apache Configuration Commons API
• Приложения C # / VB.NET делают это с App.Configфайлами, доступными через ConfigurationManager .NET API
• Приложения NodeJS имеют соглашение package.jsonили помещают значения конфигурации в json-файлы, а с помощью API файловых модулей файлы легко анализировать и использовать, поскольку они в основном являются объектными литералами JavaScript .

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

Через просмотр настроек или приложение бэк-офиса

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

MediaWiki решает эту проблему аналогичным образом, автоматически генерируя LocalSettings.phpфайл в процессе первоначальной установки.

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

Самый простой способ - просто не публиковать конфиденциальные данные. Некоторые варианты:

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

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

Если у кого-то есть исходный код (или байт-код, который может быть подвергнут обратному проектированию), он сможет получить секретный ключ, запустив код в отладчике и установив точку останова в точке отправки ключа.

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

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