Секреты OAuth в мобильных приложениях
6 ответов
Да, это проблема конструкции OAuth, с которой мы столкнулись сами. Мы решили проксировать все звонки через наш собственный сервер. OAuth не был полностью исключен из настольных приложений. Не существует идеального решения проблемы, которую я нашел без изменения OAuth.
Если подумать и задать вопрос, почему у нас есть секреты, в основном это касается предоставления и отключения приложений. Если наш секрет будет скомпрометирован, то провайдер сможет действительно отозвать только все приложение. Поскольку мы должны встроить наш секрет в настольное приложение, мы в какой-то мере облажались.
Решение состоит в том, чтобы иметь свой секрет для каждого настольного приложения. OAuth не упрощает эту концепцию. Один из способов - попросить пользователя создать секрет самостоятельно и ввести ключ в ваше настольное приложение (некоторые приложения facebook делали что-то подобное долгое время, когда пользователь переходил и создавал facebook для настройки своих пользовательских тестов и дерьмо). Это не лучший опыт для пользователя.
Я работаю над предложением о системе делегирования для OAuth. Идея состоит в том, что, используя наш собственный секретный ключ, который мы получаем от нашего провайдера, мы могли бы выдать наш собственный делегированный секрет нашим собственным настольным клиентам (в основном, по одному для каждого настольного приложения), а затем в процессе аутентификации мы отправляем этот ключ на верхний уровень. провайдер, который перезванивает нам и повторно подтверждает у нас. Таким образом, мы можем отозвать собственные секреты, которые мы выдаем каждому настольному клиенту. (Заимствуя многое из того, как это работает с SSL). Вся эта система была бы идеальной для дополнительных веб-сервисов, которые передают вызовы сторонним веб-сервисам.
Этот процесс также может выполняться без обратных вызовов проверки делегирования, если провайдер верхнего уровня предоставляет API для генерации и отзыва новых делегированных секретов. Facebook делает нечто подобное, позволяя приложениям facebook позволять пользователям создавать суб-приложения.
Об этой проблеме говорят в Интернете:
http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter- development-talk / browse_thread / thread / 629b03475a3d78a1 / de1071bf4b820c14 # de1071bf4b820c14
Решение Twitter и Yammer представляет собой решение для вывода аутентификации:
Процесс также может выполняться без обратных вызовов проверки делегирования, если провайдер верхнего уровня предоставляет API для генерации и отзыва новых делегированных секретов. Facebook делает нечто подобное, позволяя приложениям facebook позволять пользователям создавать суб-приложения.
Некоторые разговоры об этой проблеме ведутся в Интернете:
http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter- development-talk / browse_thread / thread / 629b03475a3d78a1 / de1071bf4b820c14 # de1071bf4b820c14
Решение Twitter и Yammer представляет собой решение для вывода аутентификации:
Этот процесс также может выполняться без обратных вызовов проверки делегирования, если провайдер верхнего уровня предоставляет API для генерации и отзыва новых делегированных секретов. Facebook делает нечто подобное, позволяя приложениям facebook позволять пользователям создавать суб-приложения.
Некоторые разговоры об этой проблеме ведутся в Интернете:
http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter- development-talk / browse_thread / thread / 629b03475a3d78a1 / de1071bf4b820c14 # de1071bf4b820c14
Решение Twitter и Yammer представляет собой решение для вывода аутентификации: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html
Как уже упоминали другие, не должно быть реальных проблем с хранением секрета локально на устройстве.
Вдобавок к этому, вы всегда можете положиться на UNIX модель безопасности Android на основе: только ваше приложение может получить доступ к тому, что вы пишете в файловой системе. Просто запишите информацию в объект SharedPreferences вашего приложения по умолчанию.
Чтобы получить секрет, нужно получить root-доступ к телефону Android.
Одним из решений может быть жесткое кодирование секрета OAuth в коде, но не , а не в виде простой строки. Обфускируйте его каким-либо образом - разбейте его на сегменты, сдвиньте символы по смещению, поверните - сделайте что-то или все из этих вещей. Взломщик может анализировать ваш байтовый код и находить строки, но код обфускации может быть трудным для понимания.
Это не надежное решение, а дешевое.
В зависимости от ценности эксплойта, некоторые гениальные взломщики могут пойти на большее, чтобы найти ваш секретный код. Вам необходимо взвесить факторы - стоимость ранее упомянутого решения на стороне сервера, стимул для взломщиков тратить больше усилий на поиск вашего секретного кода и сложность обфускации, которую вы можете реализовать.
У меня нет большого опыта работы с OAuth - но разве для каждого запроса не требуется не только токен доступа пользователя, но также ключ и секрет пользователя приложения? Таким образом, даже если кто-то украдет мобильное устройство и попытается получить с него данные, ему также понадобятся ключ и секрет приложения, чтобы иметь возможность делать что угодно.
Я всегда думал, что замысел OAuth заключался в том, чтобы каждый Том, Дик и Гарри, у которых был мэшап, не должны были хранить ваши учетные данные Twitter в открытом виде. Я думаю, что, несмотря на свои ограничения, он неплохо решает эту проблему. Кроме того, он не был разработан специально для iPhone.
Здесь есть над чем подумать. Google предлагает два метода OAuth ... для веб-приложений, где вы регистрируете домен и генерируете уникальный ключ, и для установленных приложений, где вы используете ключ «анонимно».
Возможно, я что-то упустил в чтении, но кажется, что совместное использование уникального ключа вашего веб-приложения с установленным приложением, вероятно, более безопасно, чем использование «анонимности» в методе официальных установленных приложений.
Facebook, строго говоря, не реализует OAuth (пока), но они реализовали способ не встраивать свой секрет в приложение для iPhone: https://web.archive.org/web/20091223092924/http://wiki.developers.facebook.com/index.php/Session_Proxy
Что касается OAuth, да, чем больше я думаю об этом, мы немного чучело. Возможно, это исправит это.