Не хотите хранить секретный API-ключ Facebook/Twitter на мобильных устройствах, шаблонах проектирования?

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

Итак, какие варианты для меня? Я бы предположил, что частный сервер имеет секретный ключ API и веб-службу, которая инкапсулирует все вызовы методов. Поэтому вместо того, чтобы мобильное устройство имело секретный ключ и делало что-то вроде:
List<Friends> = service.GetFriends(secretKey);

Если мой секретный ключ API скомпрометирован и используется для рассылки спама/злоупотреблений, я должен прекратить использование для всех своих пользователей, оставив мое приложение мертвым в море.

Итак, моя идея состоит в том, что я могу использовать уникальный идентификатор мобильного устройства и делать следующее:
List<Friends> = myService.GetFriends(deviceID);

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

Об истинной PKI, вероятно, не может быть и речи, поскольку целевое устройство не обрабатывает клиентские HTTP-сертификаты в текущей версии.

Любые другие хорошие идеи?


person Magnus Johansson    schedule 15.11.2010    source источник


Ответы (1)


Вы не хотите публиковать свой ключ API в Facebook или Twitter, даже запутанный в клиенте.

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

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

TL;DR

Защитите ключи API вашей платформы. Защитите свой собственный API в достаточной степени, чтобы защитить свои потребности.

person Winfield    schedule 28.02.2011