Як захистити таємницю споживача OAuth та як реагувати, коли це порушено?

Це питання стосується спроби зрозуміти ризики безпеки, пов’язані з впровадженням aauth на мобільній платформі, як Android. Припущення полягає в тому, що у нас є програма для Android, яка має ключ / секрет споживача, вбудований у код.

Якщо припустити, що споживча таємниця була скомпрометована, і хакер її здобув, які наслідки від цього?

Компрометовані
споживчі таємничі припущення. Чи правильно я стверджую, що компрометована споживча таємниця як така не впливає на безпеку користувача або будь-які дані, що зберігаються у постачальника з підтримкою OAuth, з яким користувач взаємодіяв. Самі дані не скомпрометовані і хакер не може їх отримати.

Хакеру потрібно було б дістати дійсний токен доступу користувача, і це набагато складніше отримати.

Що може зробити хакер із компрометованим споживчим секретом?
Я також правильно зазначив наступне:

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

Вплив на кінцевого користувача
За умови, що

• хакер встановив програму / сайт, використовуючи мою споживчу таємницю
• одного з моїх користувачів було підмануто дозволити доступ до цієї програми / сайту

Може статися таке:

• кінцевий користувач може помітити, що щось неприємне, і повідомити постачальника послуг (наприклад: Google) про шкідливий додаток
• Потім постачальник послуг може відкликати ключ / секрет споживача

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

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

Альтернативи
Чи існують альтернативи для цього проксі-інгу? Чи можна зберігати споживчу таємницю на проміжному веб-сервері та мати якийсь механізм, за допомогою якого програма Android (опублікована на ринку та належним чином підписана) може зробити надійний запит на проміжний веб-сервер для отримання споживчої таємниці та її збереження внутрішньо в додатку? Чи може бути реалізований механізм, за яким проміжний веб-сервер "знає", що це офіційний додаток для Android, який вимагає отримати споживчу таємницю, і що проміжний веб-сервер буде передавати лише споживчий секрет до цього конкретного додатка для Android?

Короткий зміст : Я просто піду на ризик і збережу таємницю в клієнтському додатку.

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

Єдиним способом, яким ви можете розумно пом’якшити перелічені нижче проблеми та змусити роботу проксі-сервера, було б пройти цілих дев’ять ярдів - перенести всю бізнес-логіку для роботи з ресурсами сторонніх веб-служб на ваш проксі-сервер і зробити клієнтський додаток німим терміналом з розширеним інтерфейсом. Таким чином, єдині дії, які шкідливий додаток зможе змусити проксі виконувати від свого імені, - це лише те, що законно потрібно вашій бізнес-логіці.

Але тепер ви потрапляєте в цілу низку інших проблем, що мають справу з надійністю та масштабованістю.

Довге обговорення того, чому простий проксі не працює :

Деякі люди, стикаючись з проблемою, думають: "Я знаю, я додаю свій проксі-сервер". Тепер у них дві проблеми. (з вибаченнями перед Джеймі Завінським)

Ваші припущення в основному правильні. Точно до того моменту, коли ви починаєте думати про свій власний сервер, чи зберігає він таємницю та проксі-сервери викликів для клієнтської програми, чи намагається визначити, чи є програма законною та надати їй секрет. В обох підходах вам все одно доведеться вирішити проблему "чи цей запит походить від фрагменту коду, який я написав"?

Повторюся - немає можливості розрізнити по дроту, що працює певна частина програмного забезпечення. Якщо дані в повідомленнях виглядають правильно, ніщо не може довести, що це інша програма, яка надсилає це повідомлення .

Зрештою, якщо я пишу шкідливий додаток, мені байдуже, чи справді я знаю справжню таємницю, якщо я можу змусити когось, хто знає, що він робить роботу від мого імені. Отже, якщо ви вважаєте, що зловмисна програма може видавати вашу програму за сторонні сервери OAuth, чому ви впевнені, що вона не може видавати вашу програму за ваш проксі?

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

Почну з очевидного - неможливо розрізнити по дроту, що працює певна частина програмного забезпечення. Якщо дані в повідомленнях виглядають правильно, ніщо не може довести, що це інша програма, яка надсилає це повідомлення.

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

Звичайно, слабким місцем тут є те, що досить хороший додаток може змусити користувача довіряти йому і не відкликати облікові дані, перш ніж він закінчить свої нечесні справи.

Однак одним із способів пом'якшити це є підхід Google щодо використання 3-ногового OAuth замість стандартного 2-ногого. У OAuth із 3 ногами немає попередньо призначеного секрету, але при кожній автентифікації видається новий секрет маркера доступу разом із кожним маркером доступу. Хоча в кінцевому рахунку це страждає тим самим недоліком, оскільки погана програма може прочитати секрет токена хорошої програми зі свого процесу, але це призводить до того, що користувач повинен схвалювати доступ до програми кожного разу, коли йому потрібен новий маркер доступу.

І звичайно, це також означає, що це трохи незручніше і дратує користувача.