Найкращий спосіб приховати ключ API у вихідному коді

Мені потрібні деякі ідеї, як захистити приватний ключ API в додатку, зокрема в додатку ac # .NET.

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

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

Буду дуже вдячний будь-яким ідеям, як я можу це зробити.

Узагальнити:

• У вас є ключ API, виданий вам постачальником, щоб ви могли використовувати його API, і ви зобов’язані запобігти тому, щоб цей ключ був відомий будь-хто інший
• Ви здійснюєте дзвінки до API цього постачальника (для якого потрібен ключ API) у коді програми
• Ви розгортаєте додаток у системах, де клієнти мають доступ до бінарних файлів і, таким чином, можуть потенційно декомпілювати / знеструмувати код або перехопити трафік

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

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

Я бачу два основних способи досягти цього, обидва з яких не включають ваш приватний ключ API у розгорнутому додатку:

Отримайте унікальний ключ API для кожного розгортання

Це потребує додаткових стосунків з продавцем, де ви можете отримати ключі або замовити клієнтів.

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

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

Використовуйте проксі

Налаштуйте проксі-сервер, де ваша програма викликає ваш API (на ваших серверах), а в свою чергу, API викликає API постачальника за допомогою ключа.

Можливо, вам знадобиться додатковий захист вашого API, наприклад, щось для того, щоб забезпечити його використання лише вашою програмою. Це можна зробити:

• що робить цю функціональність настільки специфічною, що тільки ваша програма не може її використовувати
• Білі списки IP-адрес
• Деякі існуючі механізми ліцензування / авторизації, які ви вже маєте для своїх серверів
• Ваша власна система ключів API, де ви можете видавати ключі своїм клієнтам

Тут потрібно пам’ятати, що ви можете не допустити цього. У вашого постачальника можуть бути Умови надання послуг або юридичні договори, які не дозволяють вам створити "службу збору даних" або проксі-сервера, тому вам потрібно перевірити це.

Поводження з поведінкою

Навіть якщо ваш ключ не порушений, якщо хтось із ваших клієнтів робить щось, що змушує постачальника заблокувати ваш ключ, раптом ВСІ ваші клієнти відключені, і ваш єдиний виправлення - оновити всіх інших.

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

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

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

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

Тому не вкладайте його. "Єдиний виграшний хід - це не грати".

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