Насколько безопасны секретные ключи в приложениях Windows 8 (WinJs)?

Я делаю хобби-проект Windows 8 app на WinJS. Поскольку я вызываю внешний api, для которого требуется ключ api и аутентификация oauth, у меня есть несколько ключей, которые мне нужно держать в секрете.

Я видел в Интернете места с подробными описаниями того, как получить доступ к приложениям WinJ (и C #) на вашем компьютере, а также изменить их исходный код. Но я думаю, что это были временные рамки бета-версии / предварительного просмотра?

Мои навыки Google, похоже, не могут сказать мне, было ли это исправлено с тех пор, кто-нибудь знает?

Если это не было исправлено, как люди справляются с такими ситуациями?

Любые советы и предложения приветствуются :)


security secret-key winjs code-access-security windows-8
person Ola Karlsson    schedule 22.08.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

У вас есть пара вариантов.

  1. Интегрируйте мобильные службы Azure и, если возможно, сделайте oAuth. Ваши ключи остаются секретными в облаке.
  2. Храните основной ключ в зашифрованном виде в вашем приложении WinJs. Затем секрет также зашифровывается и хранится локально. Я использую https://github.com/cauld/winjs-oauth-for-twitter и внесем небольшую поправку: когда я получу ключ, я сохраню его в диспетчере учетных данных.

Любое локальное приложение, скомпилированное на любом компьютерном языке, можно подделать, все, что вам нужно, - это отладчик. Если вы зашифруете все, что я теоретически могу просто загрузить отладчик, присоединиться к библиотеке стека http и смотреть, как данные уходят (исключая даже более простые методы, такие как Fiddler для просмотра этих данных), и извлекать все, что я хочу - довольно легко. Итак, вопрос в том, что вы пытаетесь предотвратить?

person Adam Tuliper - MSFT    schedule 23.08.2013
comment
Re: 1 Я собирался подписаться на пробную учетную запись Azure, но, к сожалению, регистрация не работает :( Re: 2 Когда вы говорите - Храните основной ключ в зашифрованном виде, вам также придется хранить ключ для расшифровки, поэтому тогда нет смысла его шифровать, или? - person Ola Karlsson; 26.08.2013
comment
Зашифруйте его, используя локальные хранимые механизмы, такие как хранилище паролей. Это не полностью защищено от вмешательства клиента, но в целом является подходящим уровнем защиты. Такова проблема с любым ключом, который требуется на стороне клиента - вы не можете полностью предотвратить доступ к нему. Это типично для приложений oAuth, которые работают от клиента. Что случилось с Azure? Вы можете написать мне на adamt @ ms скриншот / описание? - person Adam Tuliper - MSFT; 26.08.2013

arrow_upward
0
arrow_downward

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

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

person Sheng Jiang 蒋晟    schedule 22.08.2013