Секрети OAuth у мобільних додатках

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

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

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

Єдине дієве рішення, яке я можу придумати, - спершу отримати токен доступу як звичайний (бажано, використовуючи веб-перегляд всередині додатка), а потім прокласти все подальше спілкування через наш сервер, який додасть секрет до даних запиту та спілкуватиметься з провайдером. Знову ж таки, я нобі-охоронець, тому мені дуже хотілося б почути думки людей з цього приводу. Мені не здається, що більшість додатків збираються настільки довго, щоб гарантувати безпеку (наприклад, Facebook Connect, здається, припускає, що ви вводите секрет у рядок прямо у вашому додатку).

Інша річ: я не вірю, що секрет пов'язаний з тим, щоб спочатку запросити маркер доступу, щоб це можна було зробити без залучення власного сервера. Я прав?

Так, це проблема з дизайном 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

За допомогою OAUth 2.0 ви можете зберігати секрет на сервері. Використовуйте сервер, щоб придбати маркер доступу, який ви перемістите в додаток, і ви зможете здійснювати дзвінки з програми на ресурс безпосередньо.

За допомогою OAuth 1.0 (Twitter) секрет необхідний для здійснення дзвінків API. Проксі-сервер дзвінків через сервер - єдиний спосіб запобігти невзбиранню секрету.

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

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

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

Це не дурне захисне рішення, а дешеве.

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

Не зберігайте секрет всередині програми.

Потрібно мати сервер, до якого програма може отримати доступ через https (очевидно), і ви зберігаєте на ньому секрет.

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

Тоді, якщо вам потрібно отримати будь-яку конфіденційну інформацію з сервісу (facebook, google, twitter тощо), програма запитає ваш сервер, і ваш сервер передасть її до програми, лише якщо вона правильно підключена.

Насправді немає жодного варіанту, окрім зберігання на сервері. Ніщо на стороні клієнта не є безпечним.

Примітка

При цьому це захистить вас лише від зловмисного клієнта, але не від клієнта від зловмисного вас, а не від інших зловмисних клієнтів (фішинг) ...

OAuth - набагато кращий протокол у браузері, ніж у настільному / мобільному.

Існує нове розширення до типу наданого коду авторизації під назвою ключ підтвердження для обміну кодом (PKCE) . З цим вам не потрібен секрет клієнта.

PKCE (RFC 7636) - це техніка захисту публічних клієнтів, які не використовують секрет клієнта.

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

з https://oauth.net/2/pkce/

Для отримання додаткової інформації ви можете прочитати повний RFC 7636 або це коротке вступ .

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

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

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

Приємний опис того, як це реалізувати, можна знайти тут: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

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

Я завжди думав, що намір за OAuth полягає в тому, щоб кожен Том, Дік та Гаррі, які мали мешанку, не повинні зберігати ваші облікові дані Twitter. Я думаю, що це досить добре вирішує цю проблему, незважаючи на обмеження. Крім того, він насправді не був розроблений з урахуванням iPhone.

Я згоден з Феліксизом. У той час як OAuth краще, ніж Basic Auth, все ще має пройти довгий шлях, щоб стати гарним рішенням для мобільних додатків. Я грав із використанням OAuth для аутентифікації програми мобільного телефону в додатку Google App Engine. Те, що ви не можете надійно керувати споживчою таємницею на мобільному пристрої, означає, що за замовчуванням використовується "анонімний" доступ.

Крок авторизації веб-переглядача впровадження Google App Engine OAuth перенаправляє вас на сторінку, де він містить текст на зразок: "Сайт <сайт-просити> вимагає доступу до вашого облікового запису Google для продуктів, перелічених нижче".

YourApp (yourapp.appspot.com) - не пов’язаний з Google

тощо

<some-site> з домену / імені хоста, використовуваного в URL-адресі зворотного дзвінка, який ви надаєте, який може бути будь-яким на Android, якщо ви використовуєте власну схему для перехоплення зворотного дзвінка. Отже, якщо ви використовуєте "анонімний" доступ або ваша конфіденційність споживача порушена, тоді будь-хто може написати споживача, який обдурить користувача, щоб отримати доступ до вашої програми gae.

Сторінка авторизації Google OAuth також містить безліч попереджень, які мають 3 рівні суворості залежно від того, використовуєте ви "анонімні", таємниці споживачів або відкриті ключі.

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

У цьому дописі в блозі роз'яснено, як секрет споживачів насправді не працює з встановленими програмами. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

Я також намагаюся розробити рішення для аутентифікації мобільного OAuth та загального зберігання секретів у пакеті додатків.

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

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

Це буде працювати?

Тут я маю відповідь про безпечний спосіб зберігання вашої інформації oAuth у мобільному додатку

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

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

Facebook не застосовує OAuth строго кажучи (поки), але вони реалізували спосіб, щоб ви не вставляли свою таємницю в додаток для iPhone: https://web.archive.org/web/20091223092924/http://wiki. developers.facebook.com/index.php/Session_Proxy

Щодо OAuth, так, чим більше я думаю про це, ми трохи забиті. Можливо, це виправить.

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

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

Таким чином, навіть якщо секрет порушений, хакер зможе користуватися ним лише максимум 5 хвилин.

Як зазначали інші, зі зберіганням секрету локально на пристрої не повинно виникати справжніх проблем.

Крім того, ви завжди можете розраховувати на модель безпеки Android на основі UNIX: лише ваша програма може отримати доступ до того, що ви пишете у файловій системі. Просто запишіть інформацію в об'єкт SharedPreferences за замовчуванням для програми.

Щоб отримати секрет, потрібно було б отримати кореневий доступ до телефону Android.