Лучшие практики для хранения и защиты закрытых ключей API в приложениях [закрыто]


373

Большинство разработчиков приложений интегрируют в свои приложения сторонние библиотеки. Если это для доступа к службе, например Dropbox или YouTube, или для регистрации сбоев. Количество сторонних библиотек и сервисов просто поражает. Большинство этих библиотек и сервисов интегрированы путем какой-либо аутентификации с сервисом, в большинстве случаев это происходит через ключ API. В целях безопасности сервисы обычно генерируют открытый и закрытый, часто называемый секретным ключом. К сожалению, для подключения к сервисам этот закрытый ключ должен использоваться для аутентификации и, следовательно, вероятно, быть частью приложения. Само собой разумеется, что это сталкивается с огромной проблемой безопасности. Открытые и закрытые ключи API могут быть извлечены из APK за считанные минуты и могут быть легко автоматизированы.

Предполагая, что у меня есть что-то похожее на это, как я могу защитить секретный ключ:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

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



я сохранил в image / png и получил ключ через png как BufferReader
Sumit

Я думаю, что это серьезная проблема, и опубликовал похожую проблему на странице github Firebase Android SDK: github.com/firebase/firebase-android-sdk/issues/1583 . Давайте посмотрим, будет ли это обработано.
Гребулон

Ответы:


348
  1. В действительности ваше скомпилированное приложение содержит ключевые строки, а также имена констант APP_KEY и APP_SECRET. Извлечение ключей из такого самодокументируемого кода тривиально, например, с помощью стандартного инструмента Android dx.

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

    Обратите внимание, что настройка ProGuard не должна быть такой сложной, как вы боитесь. Для начала вам нужно только включить ProGuard, как описано в project.properties. Если есть какие-либо проблемы со сторонними библиотеками, вам может потребоваться скрыть некоторые предупреждения и / или предотвратить их запутывание в proguard-project.txt. Например:

    -dontwarn com.dropbox.**
    -keep class com.dropbox.** { *; }
    

    Это подход грубой силы; Вы можете уточнить такую ​​конфигурацию, как только обработанное приложение заработает.

  3. Вы можете запутать строки вручную в своем коде, например, с помощью кодировки Base64 или, предпочтительно, с более сложным; возможно даже родной код. Затем хакеру придется статически пересмотреть кодировку или динамически перехватить декодирование в нужном месте.

  4. Вы можете применить коммерческий обфускатор, как специализированный брат ProGuard DexGuard . Он может дополнительно зашифровать / запутать строки и классы для вас. Извлечение ключей требует еще больше времени и опыта.

  5. Возможно, вы сможете запустить части своего приложения на своем собственном сервере. Если вы можете хранить ключи там, они в безопасности.

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

(Я разработчик ProGuard и DexGuard)


2
@EricLafortune не имеет значения, если строка закрытого ключа хранится в классе Java против XML-ресурса String?
Алан

1
@EricLafortune Теперь возможно ли использовать систему Android Keystore для безопасного хранения ключей? ( developer.android.com/training/articles/keystore.html )
Дэвид Томас,

1
@DavidThomas: вы пытались использовать хранилище ключей. Я хочу запутать ключ API, написанный на Java-классе. Пожалуйста, ответьте
Сагар Трехан

1
Android KeyStore полезен для этого? ( developer.android.com/training/articles/… )
Вейши Цзэн,

1
Я не понимаю # 5. Разве у него нет таких же точных проблем, как у исходной проблемы?
Pete

80

Мало идей, на мой взгляд, только первая дает некоторую гарантию:

  1. Храните свои секреты на каком-то сервере в Интернете, а при необходимости просто берите их и используйте. Если пользователь собирается использовать Dropbox, ничто не мешает вам сделать запрос на ваш сайт и получить ваш секретный ключ.

  2. Поместите свои секреты в код jni, добавьте переменный код, чтобы сделать ваши библиотеки больше и сложнее декомпилировать. Вы также можете разбить строку ключа на несколько частей и хранить их в разных местах.

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

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

Если вы хотите быстро взглянуть на то, как легко читать ваш apk-код, тогда скачайте APKAnalyser:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/


46
если пользователь может декомпилировать приложение, хотя он может определить запрос на ваш собственный сервер и просто выполнить его, чтобы получить секрет. Никакой серебряной пули здесь, но сделайте несколько шагов, и я держу пари, что вы будете в порядке! Если ваше приложение очень популярно, хотя, возможно, нет .. Великие идеи!
Мэтт Вулф

3
да, номер 1 не дает никаких гарантий.
marcinj

42
Мне очень нравится идея скрывать ключи внутри изображений. +1
Игорь Чордаш

1
@ MarcinJędrzejewski Хотели бы вы объяснить больше (с примером или кодом предпочтительно) о четвертом решении? Спасибо.
Dr.jacky

2
@ Mr.Hyde это называется стеганография, слишком сложно, чтобы привести пример кода здесь, вы можете найти примеры в Google. Я нашел один здесь: dreamincode.net/forums/topic/27950-steganography . Идея замечательная, но поскольку код apk можно декомпилировать, он портит его красоту.
marcinj

32

Другой подход заключается в том, чтобы вообще не иметь секрета на устройстве! См. Техника безопасности мобильного API (особенно часть 3).

Используя проверенную временем традицию косвенного обращения, поделитесь секретом между конечной точкой API и службой аутентификации приложения.

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

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

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

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


5
Это должен быть принятый ответ.
ортономия

4
Проблема сохраняется, когда вы хотите получить доступ к службе аутентификации. Это даст вам идентификатор клиента и секрет клиента. Где мы должны их сохранить?
Аши

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

25

Старый необеспеченный путь:

Выполните 3 простых шага для защиты API / секретного ключа ( старый ответ )

Мы можем использовать Gradle для защиты ключа API или секретного ключа.

1. gradle.properties (Свойства проекта): создать переменную с ключом.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Module: app): Установите переменную в build.gradle, чтобы получить доступ к ней в действии или фрагменте. Добавьте приведенный ниже код для buildTypes {}.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Получите доступ к нему в Activity / Fragment с помощью BuildConfig приложения:

BuildConfig.GoogleSecAPIKEY

Обновить :

Приведенное выше решение полезно в проекте с открытым исходным кодом для фиксации над Git. (Спасибо Дэвиду Роусону и Рияз-Али за ваш комментарий).

Согласно комментариям Мэтью и Пабло Чегарры, вышеуказанный способ небезопасен, и Декомпилятор позволит кому-то просматривать BuildConfig с нашими секретными ключами.

Решение :

Мы можем использовать NDK для защиты ключей API. Мы можем хранить ключи в собственном классе C / C ++ и получать к ним доступ в наших классах Java.

Пожалуйста, следуйте этому блогу, чтобы защитить ключи API с помощью NDK.

Продолжение о том, как безопасно хранить токены в Android


4
безопасно хранить ключ в файле Gradle?
Google

4
@ Google gradle.propertiesне должен регистрироваться в Git, так что это способ сохранить секрет в секретном исходном коде, по крайней мере
Дэвид Роусон

4
Это не препятствует тому, чтобы ключ API был включен в полученный результат apk(он будет добавлен в сгенерированный BuildConfigфайл), хотя это определенно хорошая идея для управления различными ключами API (например, в проекте с открытым исходным кодом)
riyaz-ali

5
Использование декомпилятора Java позволит кому-то просмотреть файл BuildConfig и «GoogleSecAPIKEY»
Матфея

3
Ваш BuildConfig.javaфайл будет иметь ключ в виде простого текста. Это не лучше, чем то, что уже делает ОП.
IceMar

16

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

для тех парней это не скроет, заблокируйте либо ProGuardкод. Это рефакторинг, и некоторые платные обфускаторы вставляют несколько побитовых операторов, чтобы вернуть jk433g34hg3 строку. Вы можете увеличить время взлома на 5-15 минут, если вы работаете 3 дня :)

Лучший способ - оставить все как есть, имхо.

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

Обычный пользователь не будет декомпилировать ваш код.


1
Ну - не тот ответ, который я надеялся получить =) ... Я думал, что вы можете достичь большой безопасности :(
Basic Coder

извините, это не то, что вы хотели блестящее, ультра-безопасное решение, но для тех, кто может использовать компилятор, декомпилятор не имеет безопасного java-кода: даже нативный код можно просматривать с помощью hexa viewer и decrtyped. По крайней мере, стоит попробовать ...

1
Proguard не будет запутывать фактический ключ, хотя ..? Лучшее, что можно сделать, - это какая-то простая подпрограмма encript / decript, которую будет скрывать запутывание.
Doomsknight

3
она "видима" в процедуре дешифрования, легко сделать обратное, и у вас есть оригинальная строка

14

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

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Декомпилированный исходный код защищенного приложения выглядит так:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

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

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Декомпилированная версия:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

и вы можете найти так много классов шифрования с небольшим поиском в Google.


13

В дополнение к решению @Manohar Reddy можно использовать базу данных firebase или firebase RemoteConfig (со значением по умолчанию Null):

  1. Зашифруй свои ключи
  2. Сохраните его в базе данных Firebase
  3. Получите его во время запуска приложения или при необходимости
  4. расшифровать ключи и использовать его

Чем отличается это решение?

  • нет кредитов для пожарной базы
  • Доступ к Firebase защищен, поэтому только приложение с подписанным сертификатом имеет право совершать вызовы API.
  • шифрование / дешифрование для предотвращения перехвата среднего человека. Однако звонки уже https на firebase

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

Одно преимущество, однако, с предложенным решением, мы добавляем еще одно осложнение перед хакером.
Аши

11

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

Защита секрета в пути

Первое, на что следует обратить внимание, это то, что для доступа к API Dropbox с использованием механизма аутентификации приложения вам необходимо передать свой ключ и секрет. Соединение - HTTPS, что означает, что вы не можете перехватить трафик, не зная сертификата TLS. Это сделано для предотвращения перехвата и считывания пакетов на пути от мобильного устройства к серверу. Для обычных пользователей это действительно хороший способ обеспечить конфиденциальность своего трафика.

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

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

Защищать секрет в покое

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

Более продвинутые варианты

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

Затем вам нужно решить, как лучше всего общаться с вашими серверами, чтобы обеспечить их защиту. Это важно для предотвращения повторения всех тех же проблем с вашим внутренним API. Лучшее эмпирическое правило, которое я могу дать, - не передавать какой-либо секрет напрямую из-за угрозы «человек посередине». Вместо этого вы можете подписать трафик, используя свой секрет, и проверить целостность любых запросов, поступающих на ваш сервер. Один из стандартных способов сделать это - вычислить HMAC сообщения с секретным ключом. Я работаю в компании, у которой есть продукт для обеспечения безопасности, который также работает в этой области, поэтому такого рода вещи меня интересуют. На самом деле, вот статья в блоге одного из моих коллег, которая посвящена большей части этого.

Сколько я должен сделать?

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


1
Вы просто копируете и вставляете это отсюда: hackernoon.com/mobile-api-security-techniques-682a5da4fe10 без подтверждения источника.
ортономия

1
@ortonomy Я согласен, что он должен был процитировать статью, которую вы связали, но он, возможно, забыл ее, потому что оба работают в одном месте ...
Exadra37

2
Также статья Скипа и пост в блоге, на котором они основаны, вышли через неделю после моего ответа.
ThePragmatist

8

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


32
Проблема в том, чтобы добраться до того сервера, который содержит все секреты, и я должен использовать другой секретный ключ. Интересно, где я буду его хранить? ;) То, что я пытаюсь сказать, - это тоже не лучшее решение (не думаю, что здесь есть идеальное решение)
Mercury

Это неправда, ваш сервер полностью под вашим контролем. То, что для этого требуется, полностью зависит от вас.
Бернард Игири

5
Можете ли вы объяснить, как клиент может зашифровать данные, которые он хочет отправить на сервер, в то время как ключи находятся на стороне сервера? и если ваш ответ будет - сервер отправляет ключи клиенту - так что это также должно быть защищено! так что опять нет волшебного решения! ты не видишь ?!
Меркурий

2
@BernardIgiri, а затем снова мы возвращаемся к квадрату 1. Предположим, что телефон создает случайный логин, и сервер принимает это и отправляет пин-код (это так называемый частный сервер, о котором мы говорим). Затем человек, который разбирает ваше приложение, видит, что все, что требуется для доступа к вашему частному серверу, - это просто случайный логин, который он может создать сам. Скажите, что мешает ему создать его и получить доступ к вашему серверу? На самом деле, в чем разница между вашим решением и фактическим сохранением логина или ключа API на главном сервере (учетные данные которого мы хотели сохранить на нашем частном сервере)
Кен

3
@ken Случайное число аутентифицируется по номеру телефона и физическому доступу к его текстовым сообщениям. Если кто-то обманывает вас, у вас есть их информация. Если этого недостаточно, заставьте их создать полную учетную запись пользователя и пароль. Если это не достаточно хорошо, возьмите кредитную карту тоже. Если этого недостаточно, попросите их позвонить. Если этого недостаточно, встретите их лицом к лицу. Насколько безопасным / неудобным вы хотите быть?
Бернард Игири

7

Сохраняйте секрет firebase databaseи извлекайте его при запуске приложения. Это гораздо лучше, чем вызов веб-службы.


13
а как насчет учетных данных для firebase?
the_joric

2
К сожалению, база данных Firebase не работает в Китае.
Коньенгбам

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

3
Я думаю, что это лучшее решение, так как Firebase Apps использует SHA1 для доступа к серверу. Декомпиляция кода не поможет выполнить вызов firebase, поскольку новое приложение хакера должно использовать точный штамп приложения для доступа к firebase. Кроме того, хранимый ключ должен быть зашифрован перед хранением в базе данных Firebase и расшифрован после получения, чтобы избежать перехвата посредником.
Айман Аль-Абси

Когда вы получаете секрет из базы данных firebase через сеть, как это сделать безопаснее, чем получать тот же секрет из другого веб-сервиса по безопасному каналу (https)? Вы можете объяснить?
Csaba Toth

6

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

Поэтому, если пользователь не введет PIN-код или фразу, нет способа скрыть ключ. Но для этого у вас должна быть схема для управления PIN-кодами, происходящими вне диапазона, то есть через другой канал. Конечно, не практично для защиты ключей для таких сервисов, как Google API.


5

Старый пост, но все еще достаточно хорош. Я думаю, что было бы здорово спрятать его в библиотеке .so, используя NDK и C ++. Файлы .so можно просматривать в шестнадцатеричном редакторе, но удачи в декомпиляции этого: P


9
Пользователи могут легко вызывать функции из общей библиотеки и получать все, что там скрывается. Нет необходимости разбирать это.
david72

5
Согласно androidauthority.com/…, на данный момент нет безопасного способа сделать это в Android.
Давид72

1
@AhmedAwad Не понимаю, почему это имеет 3 upvote. любой мог легко декомпилировать приложение и увидеть, как вызывается точка входа ndk: /
Johny19

1
Этот ответ является почти одним из лучших вариантов, но автор должен упомянуть, что очень важно, чтобы вы включили вызов (внутри вашей библиотеки NDK), чтобы проверить, соответствует ли контрольная сумма вашему APK, иначе кто-то может вызвать вашу библиотеку NDK за пределами ваше приложение
Стойчо Андреев

@ Снайпер, это было бы здорово, кроме как с большой проблемой. Как вы знаете, какой файл "вызывает" нативный метод? Если вы жестко запрограммировали название apk для проверки, отлично, но что если я сделаю так, чтобы мой "hack" apk был в той же папке, что и "good" apk? Он проверит, что «хороший» apk имеет хорошую контрольную сумму, и позволит мне выполнить этот нативный метод. Если нет способа узнать файл вызывающей стороны со стороны JNI / C ++, то это бессмысленно, как и другие варианты.
SocketByte

5

Единственный верный способ сохранить их в тайне - это сохранить их на вашем сервере и заставить приложение отправлять все, что угодно, на сервер, и сервер взаимодействует с Dropbox. Таким образом, вы НИКОГДА не распространяете свой закрытый ключ в любом формате.


11
Но как вы мешаете остальному миру звонить на сервер?
user2966445

Если под «сервером» вы подразумеваете свой веб-сервер, на котором находятся учетные данные, - вы можете использовать любой метод, который захотите. простая аутентификация с использованием имени пользователя / пароля, oauth, активного каталога и т. д. и т. д. Действительно зависит от вашего приложения.
Ник

Может быть, я что-то упустил, но не требует ли для этого хранения учетных данных в приложении?
user2966445

3
Правильно, но вы сказали, что приложение сначала будет аутентифицироваться на сервере. Разве это не означает хранение другого набора учетных данных в приложении? Я понимаю, что сервер будет обрабатывать фактические вызовы Dropbox.
user2966445 9.09.16

4
Ну, это может означать это, но это совершенно отдельное разрешение. Но ты не обязан. Случай использования, о котором я говорю, заключается в том, что пользователь вашего приложения будет иметь логин для вашего приложения, скажем, с помощью Facebook или Twitter. Вы не храните их учетные данные в своем приложении, вы даже не знаете их. Этот процесс авторизации позволяет им получить доступ к вашему серверу API, у которого есть учетные данные для dropbox, но ни приложение, ни пользователь не имеют к ним прямого доступа.
Ник

0

Основываясь на горьком опыте и после консультации с экспертом IDA-Pro, лучшее решение - переместить ключевую часть кода в DLL / SharedObject, затем извлечь его с сервера и загрузить во время выполнения.

Чувствительные данные должны быть закодированы, так как очень легко сделать что-то вроде этого:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD

3
И где вы храните учетные данные для указанного сервера?
ZX9
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.