2011-02-08 2 views
8

Мое приложение попадает в ряд веб-сервисов, таких как Twitter и Flickr. Он использует ключи API от этих служб, и я хотел бы запутать их в своих двоичных файлах. (Я не очень беспокоюсь о пиратстве или что-то еще, мне просто нужно хранить эти ключи в секрете.)Как защитить ключ API в приложении .NET

Каков наилучший способ?

Если я храню их как const SecureString, делает ли это их память? В описании MSDN говорится, что текст «удален из памяти компьютера, когда он больше не нужен», но не всегда является константой в памяти?

Будет ли Dotfuscator скрывать его в моей сборке? (Предполагая, что я могу получить его до work.)

+2

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

+0

Я думаю, что SecureString сделает ситуацию еще хуже. Поскольку это большой знак: «Посмотри на меня, я настолько тайна».SecureString защищает от таких вещей, как замена ключа на диск, но не на злоумышленное использование. – CodesInChaos

+0

И просто перехватить ваш запрос (т) на твиттер тоже должен быть тривиальным. – CodesInChaos

ответ

4

Anon верен, нет возможности полностью защитить данные; кто-то всегда может это получить.

Но вы хотите сделать это как можно труднее. Это означает не делать то, что делает его легким для чтения:

  • не сохраняет в разделе реестра (например, TwitterAPIKey REG_SZ)
  • не хранить в текстовом файле (например, twitterkey.txt), или в ини файле
  • не хранить в файле .config приложения
  • не хранить в виде обычного текста в бинарном
  • не хранить в открытом виде в двоичном

Это оставит людей, которые должны знать об отладчике, и (возможно) код сборки.

Вы значительно уменьшили поверхность атаки.

Следуйте только первым трем предложениям, и вам будет хорошо на вашем пути.

8

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

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

Удачи вам!

~ «dont't забудьте пить Ovaltine»

+0

Возможно ли вы разместить образец кода для вашего решения? или объяснять больше, как это работает – Smith

0

может быть, вы можете попросить вашего пользователя использовать свои собственные ключи API. Они могут зарегистрироваться на apis, а затем ссылаться на свой ключ в настройках вашего приложения

+0

Это было бы не стартером для мобильных приложений –

Смежные вопросы