Трябва ли да маскирам потребителската тайна на OAuth, съхранявана от приложението за Android?

Моето приложение за Android съдържа OAuth потребителска тайна за API на Twitter. В момента е в .properties файл в обикновен текст, така че не са необходими никакви усилия за някой да го търси в APK.

Трябва ли да предприема стъпки, за да го скрия (като rot13 или съхранен в обфусциран Java код)? Или всъщност трябва да избягвам да правя нещо от това, тъй като би създало фалшиво чувство за сигурност?

Как хората обикновено разпространяват/съхраняват OAuth тайна в приложения за Android? Колко често се случва тайната да бъде открадната и злоупотребена?


person Pēteris Caune    schedule 19.08.2011    source източник
comment
Имам същата стратегия с моето приложение за iOS и NodeJS+ExpressJS+PassportJS в задната част. Използвам обратното удостоверяване на Twitter, за да удостоверявам потребителите от iOS. Но за да осигуря това и да попреча на потребителите да надушват HTTP пакети по средата, за да разберат какво има в заглавките, планирам да използвам HTTPS на моите сървъри за криптиране на данните. Поставете отметка, за да избегнете вграждането на вашите секретни ключове в приложението ви: dev.twitter.com/ docs/ios/using-reverse-auth   -  person Maziyar    schedule 24.05.2014
comment
Забележка: Обратното удостоверяване е само за iOS   -  person Steve Tauber    schedule 30.07.2014


Отговори (4)


Истинският въпрос е какво получава един нападател, ако го открадне...

Трябва да направите всичко възможно, за да защитите тайните, но в крайна сметка силно мотивиран хакер винаги може да стигне до тях в инсталирано приложение. Така че това е стойността на тайната срещу трудността на извличането.

Стойността на тайната на клиента е имитирането на приложението. Не дава достъп до потребителски данни. Въпреки това, тъй като Twitter поддържа автоматично издаване на идентификационни данни към предварително одобрени приложения (тяхното влизане с потока на Twitter), нападателят може потенциално да изгради уеб приложение с вашата тайна и да открадне потребителски данни чрез сляпо пренасочване.

Проблемът с внедряването на Twitter е, че те не питат разработчика за естеството на приложението. Ако го направиха, те нямаше да ви издадат тайна като начало и щяха да блокират всеки, който създава уеб приложение, използвайки вашите клиентски идентификационни данни и кражба на данни от потребители, които вече са го одобрили.

Обфускацията е една възможност, но слаба. Преместването на тайната към уеб сървър, действащ като API прокси, е друго, но това просто премества проблема другаде, защото сега вашето приложение трябва да се удостоверява срещу прокси сървъра. Въпреки това, този модел може да бъде сравнително сигурен, ако изисквате потребителите да влизат във вашия сайт (който може да използва, чрез уеб изгледи, Twitter за влизане). По този начин някой, който се опитва да злоупотреби с вашето прокси, ще има нужда от своите потребители да отворят акаунти във вашата услуга, което не е много привлекателно.

Накратко, продължете и го объркайте. Не боли. Обмислете използването и на прокси шаблона. И може би да уведомите Twitter, че техните политики за сигурност „не са страхотни“.

person Eran Hammer    schedule 20.08.2011
comment
Благодаря за отговора. Приложението, върху което работя, няма да бъде социално приложение с висок профил, туитването от него е странична функция. Така че мисля, че ще направя малко обфускация, но ще пропусна добавената сложност на прокси модела. - person Pēteris Caune; 22.08.2011
comment
Страхотно е да видя моите точки подсилени от някой запознат. Въпреки че проксито премества проблема другаде, бъдещият хакер трябва да напише специфична програма, за да злоупотребява с вашето прокси. В действителност те просто ще събират потребителски тайни от други приложения - има все пак има над милион приложения на трети страни. - person David Snabel-Caunt; 22.08.2011
comment
Има URL адрес за обратно извикване в приложенията на Twitter, това ще бъде ли достатъчно, за да попречи на хакерите да създават уеб приложения, които крадат данни? Това трябва да е домейнът, който сте задали в настройките на приложението си, в противен случай той няма да упълномощи каквото и да изпратите. - person Maziyar; 24.05.2014
comment
@Eran Дори ако секретният ключ е бил обфускиран с помощта на сложен алгоритъм, има ли нещо, което спира някой да инсталира сертификат на устройството, за да го подмами да мисли, че комуникира с API на Twitter, така че да изпрати деобфусцирания ключ заедно със заявката, когато е в всъщност изпраща деобфусцирания ключ до сървъра на атакуващия? И ако е така, не е ли това упражнение за сертификат доста тривиално за изпълнение, така че какъв е смисълът да се замъглява ключът? - person Josh Sherick; 31.07.2015
comment
Има ли все пак да го поставите в iOS/Android ключодържател? - person Weishi Z; 12.08.2016

Определено бих прочел този анализ от един от Автори на OAuth, Eran Hammer-Lahav, който цитира друг статия, анализираща тайните проблеми с OAuth на Twitter.

Моят съвет би бил да скриете ключа, така че да не може тривиално да бъде извлечен и трябва да сте в безопасност от злоупотреби и спамъри.

Мнението на Hammer-Lahav е, че OAuth тайните не трябва да се отменят и трябва просто да се използват за събиране на статистика. Надяваме се, че Twitter следва този съвет.

person David Snabel-Caunt    schedule 19.08.2011
comment
Статията казва, че не използвайте клиентски тайни в инсталирани приложения и вашият съвет е да направите обратното... - person ; 19.08.2011
comment
@Graham Страхотна точка - трябваше да бъда малко по-ясен. Ако OP планира да продължи, тогава обфускацията е важна. В противен случай предполагам, че имате нужда от реализация, при която тайната се съхранява на отдалечен сървър и уеб услуга действа като прокси за OAuth извиквания. Не знам какви са най-добрите практики за този подход. - person David Snabel-Caunt; 19.08.2011

За да скриете своите OAuth секретни ключове в приложението си за Android, можете да използвате приставката gradle, която разработихме. Това е безплатна алтернатива с отворен код на Dexguard. Нашата добавка за скрити тайни-gradle използва оператора NDK и XOR, за да скрие ключовете, за да предотврати обратното инженерство.

По желание можете да предоставите персонализиран алгоритъм за кодиране/декодиране, за да подобрите сигурността на вашия ключ.

Достъп до приставката и всички подробности: https://github.com/klaxit/hidden-secrets-gradle-plugin

person Ben-J    schedule 09.11.2020

Основната точка на 0Auth е, че не съхранявате ценна чувствителна информация на устройството - така че е добре да съхранявате тайна на устройството (много по-добре от идентификационните данни на реалния потребител). В случай, че тайните на вашето устройство бъдат откраднати, потребителят винаги може да анулира достъпа, без да е необходимо да променя своите идентификационни данни

person Konstantin Pribluda    schedule 19.08.2011
comment
Да, но ако някой открие потребителската тайна на вашето приложение, той може да се преструва, че е вашето приложение. Можете да промените ключа и тайната, но тогава всичките ви инсталации в полето вече не могат да чуруликат. - person funkybro; 20.08.2011
comment
Няма начин да скриете нещо вътре в приложението си от решителен човек (дори OS 360 беше реверсивно проектирана и коригирана в машинен код в Русия). И дори ако някой се преструва, че е вашето приложение, потребителят пак ще трябва да се удостовери срещу услугата - така че няма истински компромис. - person Konstantin Pribluda; 20.08.2011
comment
Мисля, че този отговор е объркал потребителските тайни с oauth токени. - person David Snabel-Caunt; 22.08.2011