Як я можу приховати конфіденційні дані у своєму проекті з відкритим кодом?

У мене є проект з відкритим кодом, який завантажує файли в DropBox серед кількох файлових хостів. Зараз я знімаю екран на DropBox. Щоб використовувати їх API, я повинен жорстко кодувати SECRET KEY, наданий їм мені для аутентифікації OAuth. Але я боюся, що ключ не буде секретним, якщо його видно однозначно.

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

Я виявив це без відповіді питання, яке має ту ж проблему, що і моя.

Але я хотів би знати взагалі, як можна приховати конфіденційні дані у проекті з відкритим кодом.

Я маю одну ідею.

• Мати заповнювач у вихідному коді типу "<СЕКРЕТЬКИЙ КЛЮЧ ТУТ>" та заповнювати його лише під час створення бінарного файлу для випуску? (гидота!)

Якась порядна ідея?

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

Заповнювачі в коді (твердо кодовані значення)

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

Недолік цієї стратегії є те , що ключ зашитий. Отже, якщо програма поширюється у вигляді двійкової, то наявність жорсткого коду ключа не робить її особливо рентабельною.

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

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

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

Деякі мови програмування мають API, які надають це автоматично для вас, наприклад:

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

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

Через перегляд налаштувань або додаток Back Office

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

MediaWiki вирішив це аналогічно, автоматично генеруючи LocalSettings.phpфайл у початковому процесі встановлення.

Справді, це не варіант для програм, які виконуються виключно як фонові процеси, послуги чи демон. Однак саме тому ви створюєте окремі проекти GUI для них, щоб створити точку входу для налаштувань адміністрації та налаштувань у веб-додатках, які зазвичай називають додатком Back Office .

Найпростіший спосіб - просто не публікувати конфіденційні дані. Деякі варіанти:

• Використовуйте заповнювач, як у запитанні.
• Використовуйте файл заголовка спеціально для ключа, не зобов’язуйте його керувати джерелом і лише приватно поширювати його довіреним сторонам.

Я використовував другий варіант для розробки з відкритим кодом, тому що це означає, що вам не доведеться турбуватися про заповнення деталей безпосередньо перед створенням або про одну зміну, яку потрібно пам'ятати не робити.

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

Ви можете зробити це трохи складніше, поставивши попередньо складену бібліотеку C, яка розмовляє з віконцем, з ключем, закодованим у цьому, але все ще існує маса способів витікання ключів (наприклад, я думаю про рядки).

Єдиний безпечний спосіб, який я можу зробити, це зробити, - це надання веб-сервісу, який робить повідомлення для видачі. Таким чином секретний ключ залишається на вашому сервері під вашим контролем. Витрати на хостинг та пропускну спроможність означають, що це рішення є менш ніж ідеальним для безкоштовного додатку, але додатковим бонусом є те, що ваш сервер може автентифікувати клієнтів належним чином перед ретрансляцією їхніх файлів, що надсилаються в Drobox.