Как сохранить секретность потребителя OAuth безопасным и как реагировать, когда он скомпрометирован?

Этот вопрос связан с попыткой понять риски безопасности, связанные с внедрением oauth на мобильной платформе, такой как Android. Успение здесь состоит в том, что у нас есть приложение для Android, в которое встроен ключ / секрет пользователя.

Предполагая, что секрет потребителя был скомпрометирован, и хакер овладел им, каковы последствия этого?

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

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

Что может сделать хакер со скомпрометированным секретом потребителя?
Я также правильно утверждаю следующее:

  • Хакер может настроить / опубликовать приложение, которое имитирует мое приложение.
  • Хакер может привлечь пользователей, которые пройдут поток OAuth, извлекая токен доступа через хакерский танец OAuth (используя скомпрометированный потребительский ключ / секрет).
  • Пользователь может подумать, что он имеет дело с моим приложением, так как он увидит знакомое имя (потребительский ключ) во время процесса авторизации.
  • Когда потребитель выдает запрос через хакера, хакер может легко перехватить токен доступа и в сочетании с секретом потребителя теперь может подписывать запросы от моего имени, чтобы получить доступ к моим ресурсам.

Влияние конечного пользователя
В предположении, что

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

Может случиться следующее:

  • Конечный пользователь может заметить, что происходит что-то подозрительное, и сообщить поставщику услуг (например: Google) о вредоносном приложении
  • Поставщик услуг может затем отменить ключ / секрет клиента

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

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

альтернативы
Существуют ли альтернативы для этого проксирования? Можно ли хранить секрет пользователя на промежуточном веб-сервере и иметь какой-то механизм, который приложение Android (опубликованное на рынке и правильно подписанное) может сделать безопасный запрос промежуточному веб-серверу для получения секретности потребителя и его сохранения Внутри приложения? Может ли быть реализован механизм, согласно которому промежуточный веб-сервер «знает», что это официальное приложение для Android, которое запрашивает получение секретности потребителя, и что промежуточный веб-сервер будет выдавать только секрет пользователя для этого конкретного приложения для Android?

Solutions Collecting From Web of "Как сохранить секретность потребителя OAuth безопасным и как реагировать, когда он скомпрометирован?"

Резюме . Я бы просто рискнул и сохранил секрет в клиентском приложении.

Альтернатива прокси-сервера :

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

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

Долгое размышление о том, почему простой прокси не работал :

Некоторые люди, столкнувшись с проблемой, думают: «Я знаю, я добавлю свой собственный прокси-сервер». Теперь у них есть две проблемы. (Извинения Джейми Завински)

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

Позвольте мне повторить – нет способа отличить на проводе конкретную часть программного обеспечения. Если данные в сообщениях выглядят правильно, ничто не может доказать, что это другое приложение, которое отправляет это сообщение .

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

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


Я начну с очевидного – нет способа отличить на проводе, что работает определенная часть программного обеспечения. Если данные в сообщениях выглядят правильно, ничто не может доказать, что это другое приложение, которое отправляет это сообщение.

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

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

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

И, конечно же, это также означает, что это немного неудобно и раздражает пользователя.