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

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

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

Заранее извините, если это не публичная информация.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВОЗ является пользователем мобильного приложения , которое мы можем аутентификации, авторизации и идентификации несколькими способами, например , с использованием 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. Это здорово, потому что это означает, что модули могут работать для разных версий и даже ПЗУ без каких-либо изменений (пока исходный код

В устройстве, которым управляет злоумышленник, он также может использовать прокси для выполнения атаки Man in the Middle Attack для извлечения любого секрета, который вы можете использовать для определения ЧТО или КТО, как я показываю в статье « Украсть этот ключ API с человеком в атаке». :

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

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

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

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

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

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

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

Чтобы решить проблему ЧТО обеспечивает доступ к вашему мобильному приложению, вам необходимо использовать одно или все решения, упомянутые в серии статей о технологиях безопасности мобильных 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 Project - 10 основных рисков

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

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

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

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

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

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

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

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

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