Апи-токен для отдыха вызывает, где его хранить? [Дубликат]

Попробуйте это

@GET("users/{user}/repos")

Call<Response> listRepos(@Path("user") String user)

90
задан mmBs 11 July 2016 в 13:06
поделиться

5 ответов

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

Есть несколько преимуществ хранения токенов вместо фактического имени пользователя:

  • Сторонние приложения не должны знать пароль, и пользователь может быть уверен, что они отправляют его только на исходный сайт (Facebook, Twitter, Gmail и т. д.).
  • Даже если кто-то украл токен, вы не увидите пароль (который пользователь может использовать на другом сайтов)
  • Токены обычно имеют срок службы и истекают через определенное время
  • Токены могут быть отозваны, если вы подозреваете, что они были скомпрометированы
96
ответ дан Nikolay Elenkov 19 August 2018 в 03:26
поделиться
  • 1
    thx для ответа! но как я могу узнать, был ли скомпрометирован мой потребительский ключ? LOL это будет трудно сказать .. ОК о хранении токена доступа и секрет, хорошо я сохраняю их в sharedpreferences и шифрования их, но как насчет ключа клиента и секрет? Я не могу хранить их в sharedpreferences (мне нужно было бы явно написать ключ пользователя и секрет в коде, чтобы сохранить его в sharedpreference в первую очередь) .. не знаю, понимаете ли вы, что я имею в виду. – yeahman 15 April 2012 в 17:14
  • 2
    Вы должны либо поместить приложение в (несколько) запутанным способом, чтобы они не были сразу видны после декомпиляции, либо использовали собственный прокси-сервер authrorization, который имеет ключ и секрет. Положить их в приложение, очевидно, проще, и если вы думаете, что риск того, что кто-то пытается взломать ваше приложение, будет достаточно низким, возьмите этот подход. BTW, точки выше указаны для пароля пользователя. Если вы обнаружите, что ваш потребительский ключ / секрет был скомпрометирован, вы можете отменить это тоже (что, конечно же, сломает ваше приложение). – Nikolay Elenkov 16 April 2012 в 06:35
  • 3
    ok thx .. я пойду с обфускационным способом (можете ли вы порекомендовать какой-нибудь хороший инструмент для этого?) ... наличие прокси-сервера Webapp не очень привлекательно, так как мне пришлось бы заставить моих пользователей зарегистрироваться на моем сайте .. не очень удобное добавление дополнительного шага во всей цепочке ... – yeahman 16 April 2012 в 17:17
  • 4
    @NikolayElenkov: Вы писали: «Что касается шифрования, вам нужно либо потребовать от пользователя вводить дефрагментированную кодовую фразу каждый раз (таким образом, победив цель кэширования учетных данных), либо сохранить ключ в файл, и вы получите ту же проблему». , Что, если крекеры обратят ваше приложение, чтобы понять, как работает шифрование? Ваша защита может быть нарушена. Лучше ли хранить такую ​​информацию (токен, шифрование ...) с помощью собственного кода? – anhldbk 12 November 2014 в 11:03
  • 5
    Если данные приложения очищаются, то токен обновления теряется, что, вероятно, не является тем, чего хочет пользователь. – rds 21 October 2015 в 20:44

Вы можете сохранить их в AccountManager .

Вот официальное определение:

Этот класс предоставляет доступ к централизованный реестр учетных записей пользователей. Пользователь вводит учетные данные (имя пользователя и пароль) один раз на одну учетную запись, предоставляя приложениям доступ к онлайн-ресурсам с одобрением «одним щелчком».

Подробное руководство по использованию AccountManager:

Однако в конце AccountManager сохраняет ваш токен только как обычный текст. Поэтому я бы предложил зашифровать ваш секрет, прежде чем хранить их в AccountManager. Вы можете использовать различную библиотеку шифрования, такую ​​как AESCrypt или AESCrypto

. Другой вариант - использовать библиотеку Conceal . Это безопасно для Facebook и гораздо проще в использовании, чем AccountManager. Вот фрагмент кода для сохранения секретного файла с помощью Conceal.

byte[] cipherText = crypto.encrypt(plainText);
byte[] plainText = crypto.decrypt(cipherText);
13
ответ дан aldok 19 August 2018 в 03:26
поделиться
  • 1
    Хороший совет, который Скрывает. Выглядит очень прост в использовании. И для многих случаев использования. – lagos 27 April 2017 в 08:15

SharedPreferences не является безопасным местоположением. На корневом устройстве мы легко можем читать и модифицировать все приложения «SharedPrefereces xml». Даже если токен истекает каждый час, более новые жетоны все равно могут быть украдены из SharedPreferences. Android KeyStore следует использовать для долговременного хранения и извлечения криптографических ключей, которые будут использоваться для шифрования наших токенов, чтобы хранить их, например. SharedPreferences. Клавиши не сохраняются в процессе приложения, поэтому они сложнее , чтобы быть скомпрометированы.

2
ответ дан apex39 19 August 2018 в 03:26
поделиться

Ну, вы можете защитить токен доступа, выполнив следующие два параметра.

  1. Используйте сохранение токена доступа в хранилище ключей android, которое не было бы обратным.
  2. Используйте функцию NDK с некоторые вычисления, которые сохраняют ваш токен и NDK с кодом C ++, который очень трудно отменить
2
ответ дан M.Noman 19 August 2018 в 03:26
поделиться
  1. На панели проекта Android Studio выберите «Файлы проекта» и создайте новый файл с именем «keystore.properties» в корневом каталоге вашего проекта.

  1. Откройте файл «keystore.properties» и сохраните свой токен доступа и секретность в файле.

  1. Теперь загрузите прочитанный токен доступа и секретный файл build.gradle вашего модуля приложения. Затем вам нужно определить переменную BuildConfig для вашего токена доступа и секретности, чтобы вы могли напрямую обращаться к ним из своего кода. Ваш build.gradle может выглядеть следующим образом:
    ... ... ... 
    
    android {
        compileSdkVersion 26
    
        // Load values from keystore.properties file
        def keystorePropertiesFile = rootProject.file("keystore.properties")
        def keystoreProperties = new Properties()
        keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
    
        defaultConfig {
            applicationId "com.yourdomain.appname"
            minSdkVersion 16
            targetSdkVersion 26
            versionCode 1
            versionName "1.0"
            testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    
            // Create BuildConfig variables
            buildConfigField "String", "ACCESS_TOKEN", keystoreProperties["ACCESS_TOKEN"]
            buildConfigField "String", "SECRET", keystoreProperties["SECRET"]
        }
    }
    
  2. Вы можете использовать свой токен доступа и секретный код в своем коде следующим образом:
    String accessToken = BuildConfig.ACCESS_TOKEN;
    String secret = BuildConfig.SECRET;
    

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

4
ответ дан Zahidur Rahman Faisal 19 August 2018 в 03:26
поделиться
  • 1
    Похоже, нет никакой разницы в том, что создание файла свойств вместо жесткого кодирования. – Dzshean 24 January 2018 в 05:51
  • 2
    Хороший альтернативный путь. – M.Noman 30 January 2018 в 13:23
  • 3
    Я хочу написать токен во время выполнения, может быть, мой токен меняет каждый раз, когда я открываю свое приложение. – Rehan Sarwar 29 March 2018 в 14:18
  • 4
    Это очень хороший способ хранения некоторых токенов, таких как токены доступа к API. если вы хотите сохранить учетные данные пользователя, NDK - лучший способ. – TheTeslaa 31 July 2018 в 17:22
Другие вопросы по тегам:

Похожие вопросы: