Ответ 1

Я предполагаю, что они используют систему безопасности на основе "токенов", поэтому пароль на самом деле никогда не хранится нигде, просто используется для аутентификации в первый раз. Таким образом, приложение первоначально отправляет имя пользователя/пароль (через ssl), и сервер возвращает токен, который хранит приложение. Для последующих попыток синхронизации маркер отправляется первым, сервер проверяет, что он действителен, а затем позволяет отправлять другие данные.

Токен должен иметь истечение, чтобы сервер мог повторно запросить попытку аутентификации.

Если вы подключаетесь к адаптеру синхронизации из Android Framework, который даст вам возможность синхронизировать и аутентифицировать все под капотом.

http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

Если вы проверите учетные записи в разделе "Настройки" на своем устройстве, вы увидите, что я имею в виду.

Ответ 2

В основном это известный протокол OAuth использования (1)/framework (2). Несмотря на то, что он должен быть стандартом, каждый из них имел разные реализации этого протокола/структуры. Поэтому мы должны быть очень осторожны, когда речь заходит об интеграции.

Пример: Dropbox по-прежнему использует OAuth 1 и недавно приступил к поддержке OAuth 2.

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

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

Это основная иллюстрация того, как это работает.

Я обновлю ответ после получения более подробной информации об этом, так как я работаю в этой области в эти дни:)

Ответ 3

Я искал точно такую ​​же вещь и нашел способ Google, что-то вроде peterpan, но через API Google. Попробуйте эту ссылку и Google через нее, я тоже начинаю! Я отправлю новую информацию, пока я на ней!

http://developer.android.com/google/auth/http-auth.html

Ответ 4

Я новичок, но я постараюсь дать логическое решение для данного вопроса.

Будет два варианта, [1] Для каждого URI будет проверяться HTTP-аутентификация, когда пользователь вводит учетные данные, и пользователь должен получить доступ к ресурсам.

[2] Другой подход может заключаться в том, что пользователь должен пройти аутентификацию, и при каждой аутентификации будет создан уникальный токен. Используя сгенерированный токен, пользователь должен получить доступ к ресурсам.

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

Ответ 5

Пример аутентификации - это хорошее место для запуска. Android сохраняет учетные данные в Диспетчере учетных записей, вы можете просматривать учетные записи в настройках Android. Это автоматически будет хранить токены, запрашивать у пользователя учетные данные, если они истекли или пропали без вести, обновить токены и т.д. Я нахожу http-часть этого примера без или старой. Расширение андроида AccountAuthenticatorActivity - отличный помощник для анализа сериализованных данных в макет и обратно в Интернет.

Ответ 6

  Если я просто использую аутентификацию на основе имени пользователя и пароля, они не будут достаточно безопасными?

Нет, поскольку вы указываете, что ВОЗ обращается к серверу API, но не ЧТО обращается к нему.

Разница между ВОЗ и ЧТО имеет доступ к серверу API

Чтобы лучше понять различия между WHO и ЧТО обращаются к серверу API, давайте используем эту картинку:

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

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

Я надеюсь, что к настоящему моменту вы уже можете иметь представление о том, почему WHO и ЧТО не совпадают, но если нет, то это станет ясно через мгновение.

WHO является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовывать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.

OAUTH

Как правило, OAuth предоставляет клиентам "безопасный делегированный доступ" к ресурсам сервера от имени владельца ресурса. Он определяет процесс для владельцев ресурсов, чтобы разрешить сторонний доступ к своим ресурсам сервера без совместного использования своих учетных данных. Разработанный специально для работы с протоколом гипертекстовой передачи (HTTP), OAuth, по сути, позволяет выдавать маркеры доступа сторонним клиентам с помощью сервера авторизации с разрешения владельца ресурса. Затем третья сторона использует токен доступа для доступа к защищенным ресурсам, размещенным на сервере ресурсов.

OpenID Connect

OpenID Connect 1.0 - это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным способом.

Хотя аутентификация пользователя может сообщить серверу API, что ВОЗ использует API, она не может гарантировать, что запросы исходили из ЧТО, как вы ожидаете, исходной версии мобильного приложения.

Теперь нам нужен способ определить, ЧТО вызывает API-сервер, и здесь все становится сложнее, чем может показаться большинству разработчиков. ЧТО - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряется в сервере API с помощью такого инструмента, как Postman?

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

Ну, чтобы определить ЧТО, разработчики склонны прибегать к API-ключу, который обычно они жестко кодируют в коде своего мобильного приложения. Некоторые разработчики делают все возможное и вычисляют ключ во время выполнения в мобильном приложении, таким образом, он становится секретом времени выполнения, в отличие от прежнего подхода, когда в код встроен статический секрет.

Приведенная выше статья была взята из статьи, которую я написал, озаглавленной "ПОЧЕМУ ВАШЕМУ МОБИЛЬНОМУ ПРИЛОЖЕНИЮ НУЖЕН КЛЮЧ API", и которую вы можете прочитать полностью здесь, это первая статья в серии статей о ключах API.

Хранение конфиденциальных данных на клиентском устройстве

И я не могу сохранить это имя пользователя/пароль на устройстве из соображений безопасности? Должен ли я выдавать GUID для каждого пользователя при регистрации, сохранять его на своем устройстве и получать каждый раз во время запроса API?

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

Фрида

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

Экспоузд

Xposed - это фреймворк для модулей, которые могут изменять поведение системы и приложений, не касаясь каких-либо APK. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (при условии, что исходный код

В устройстве, контролируемом злоумышленником, он также может использовать прокси-сервер для выполнения атаки "Человек в середине", чтобы извлечь любой секрет, который вы можете использовать для идентификации ЧТО или ВОЗ, как я показываю в статья украсть этот ключ API с человеком в атаке:

Хотя мы можем использовать передовые методы, такие как JNI/NDK, чтобы скрыть ключ API в коде мобильного приложения, это не помешает кому-либо выполнить MitM-атаку для кражи ключа API. На самом деле атака MitM проста до такой степени, что ее могут достичь даже не разработчики.

И что теперь... Я обречен на то, что не могу защитить свой сервер API от злоупотреблений??? Не тихо, так что... надежда все еще существует !!!

Возможные решения

Может кто-нибудь сказать мне, какой метод используют известные приложения для Android, такие как Facebook, FourSquare или Twitter, для аутентификации каждого запроса, поступающего от их мобильного приложения на их сервер?

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

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

Таким образом, все, что работает на стороне клиента и нуждается в некотором секрете для доступа к API, может быть использовано по-разному, и вы можете узнать больше о этой серии статей о методах безопасности Mobile API. В этой статье вы узнаете, как можно использовать ключи API, токены доступа пользователей, HMAC и TLS Pinning для защиты API и как их можно обойти.

Для решения проблемы ЧТО обращается к вашему мобильному приложению, вам нужно использовать одно или все решения, упомянутые в серии статей о технологиях безопасности Mobile API, о которых я упоминал выше, и согласились с тем, что они могут осуществлять только несанкционированный доступ к вашему API-серверу сложнее обойти, но не невозможно.

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

Аттестация мобильного приложения

Использование решения для аттестации мобильных приложений позволит серверу API знать, ЧТО отправляет запросы, что позволяет отвечать только на запросы от подлинного мобильного приложения, отклоняя все другие запросы из небезопасных источников.

Роль решения для аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано, не запущено на корневом устройстве, не оснащено инструментарием, таким как xPposed или Frida, не подвергается атаке MitM, и это достигается путем запуска SDK в фоновом режиме. Служба, работающая в облаке, будет бросать вызов приложению, и на основе ответов она будет подтверждать целостность мобильного приложения и устройства, на котором оно работает, поэтому SDK никогда не будет нести ответственность за любые решения.

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

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

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

Сервис аттестации мобильных приложений уже существует в качестве решения SAAS в Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие. Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой. Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.

Заключение

В конце концов, решение, которое будет использоваться для защиты вашего API-сервера, должно быть выбрано в соответствии со стоимостью того, что вы пытаетесь защитить, и с юридическими требованиями к данным такого типа, такими как нормативы GDPR в Европе.

ВЫ ХОТИТЕ ПОЛУЧИТЬ ДОПОЛНИТЕЛЬНУЮ МИЛЮ?

Проект OWASP Mobile Security - Топ-10 рисков

OWASP Mobile Security Project - это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки защищенных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски мобильной безопасности и обеспечить средства контроля развития, чтобы уменьшить их влияние или вероятность эксплуатации.

Ответ 7

Имя пользователя и пароли могут быть безопасны при размещении в SharedPreferences. Использование https при подключении к серверу должно быть достаточно хорошим.