Секреты OAuth в мобильных приложениях

Question

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

Хранение строки в приложении явно нехорошо, так как кто-то может легко ее найти и злоупотребить.

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

Единственное работоспособное решение, которое я могу придумать, - это сначала получить токен доступа в обычном режиме (предпочтительно с использованием веб-представления внутри приложения), а затем направить всю дальнейшую связь через наш сервер, который добавит секрет в запрос данные и общаться с провайдером. С другой стороны, я новичок в области безопасности, поэтому мне бы очень хотелось услышать мнение некоторых знающих людей по этому поводу. Мне не кажется, что большинство приложений идут на все, чтобы гарантировать безопасность (например, Facebook Connect предполагает, что вы поместили секрет в строку прямо в своем приложении).

Другое дело: я не верю, что секрет заключается в первоначальном запросе токена доступа, так что это можно сделать без участия нашего собственного сервера. Я прав?

Answer 1

Да, это проблема дизайна 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 - это решение для аутентификации: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Answer 2

С помощью OAUth 2.0 вы можете хранить секрет на сервере. Используйте сервер для получения токена доступа, который вы затем перемещаете в приложение, и вы можете напрямую звонить из приложения в ресурс.

В OAuth 1.0 (Twitter) секрет необходим для выполнения вызовов API. Прокси-вызовы через сервер - единственный способ убедиться, что секрет не взломан.

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

(я редактор спецификации OAuth 2.0)

Answer 3

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

Это не надежное решение, а дешевое.

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

Answer 4

Не храните секрет внутри приложения.

Вам необходимо иметь сервер, к которому приложение может получить доступ через https (очевидно), и вы храните секрет на нем.

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

Тогда, если вам нужно получить какую-либо конфиденциальную информацию от службы (facebook, google, twitter и т. Д.), Приложение запросит ваш сервер, и ваш сервер передаст ее приложению, только если оно правильно подключено.

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

Примечание

Тем не менее, это защитит вас только от злонамеренного клиента, но не клиента от злонамеренного вас и не клиента от других вредоносных клиентов (фишинг) ...

OAuth - намного лучший протокол в браузере, чем на настольном / мобильном.

Answer 5

С OAuth 2.0 вы можете просто использовать поток на стороне клиента для получения токена доступа и затем использовать этот токен доступа для аутентификации всех дальнейших запросов. Тогда тебе вообще не нужен секрет.

Хорошее описание того, как это реализовать, можно найти здесь: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Answer 6

Вот о чем подумать. Google предлагает два метода OAuth ... для веб-приложений, где вы регистрируете домен и генерируете уникальный ключ, и для установленных приложений, в которых вы используете ключ «анонимный».

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

Answer 7

Существует новое расширение типа предоставления кода авторизации, которое называется Ключ подтверждения для обмена кодами (PKCE) . С ним вам не нужен секрет клиента.

PKCE (RFC 7636) - это метод защиты публичных клиентов, которые не используют секрет клиента.

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

от https://oauth.net/2/pkce/

Для получения дополнительной информации вы можете прочитать полное RFC 7636 или этого краткого введения .

Answer 8

Ни одно из этих решений не позволяет определенному хакеру прослушивать пакеты, отправленные с их мобильного устройства (или эмулятора), для просмотра секрета клиента в заголовках http.

Одним из решений может быть наличие динамического секрета, который состоит из временной метки, зашифрованной с помощью частного ключа и алгоритма двустороннего шифрования. Затем служба расшифровывает секрет и определяет, является ли отметка времени +/- 5 минут.

Таким образом, даже если секрет будет раскрыт, хакер сможет использовать его не более 5 минут.

Answer 9

Здесь я отвечу безопасным способом хранения вашей oAuth-информации в мобильном приложении

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Answer 10

Я также пытаюсь найти решение для проверки подлинности OAuth для мобильных устройств и хранить секреты в комплекте приложений в целом.

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

Итак, чтобы прояснить мою идею, вы выбираете строку, определенную ОС, не имеет значения, какая именно. Затем зашифруйте свой секрет, используя эту строку в качестве ключа, и сохраните его в своем приложении. Затем во время выполнения расшифруйте переменную с помощью ключа, который является просто константой ОС. Любой хакер, заглядывающий в ваш бинарный файл, увидит зашифрованную строку, но без ключа.

Будет ли это работать?