Обеспечение связи с мобильным приложением?

Приложение Android / Iphone будет получать доступ к данным приложения с сервера. [Django-Python]

Как я могу обеспечить связь с мобильным приложением?

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

Мои требования :

  • Аутентификация [Разрешено только приложение]
  • Целостность [Сообщения не должны изменяться между ними]
  • Конфиденциальность [Коммуникация не должна читаться, если ее обнюхивать]

Мои усилия :

  • SSL аутентифицирует только сервер, а не клиент.
  • Я не могу использовать симметричное шифрование [Предоставляет только конфиденциальность]
  • Цифровая подпись невозможна [Lacks Privacy]
  • PGP заполняет все 3 требования.

Проблема :

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

Итак, как я могу двигаться дальше? Как индустрия справляется с этим?

Должен ли я применять случайный подход:

  • Использовать простой SSL и пересечь пальцы? , Поскольку аутентификация невозможна, если ключи украдены? (Возможно только аутентификация сервера)

Обновить:

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

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

Вот высокоуровневый подход. Создайте сертификат самоподписанного сервера SSL и разверните его на своем веб-сервере. Если вы используете Android, вы можете использовать keytool, входящий в комплект Android SDK для этой цели; Если вы используете другую платформу приложений, например iOS, для них существуют аналогичные инструменты. Затем создайте самозаверяющий клиент и разверните его в своем приложении в пользовательском хранилище ключей, включенном в ваше приложение, в качестве ресурса (keytool также создаст это приложение). Настройте сервер, требующий проверки подлинности на стороне клиента, и только принять сертификат клиента, который вы создали. Настройте клиента для использования этого сертификата на стороне клиента, чтобы идентифицировать себя и принять только тот серверный сертификат, который вы установили на своем сервере для этой части.

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

Шаг за шагом для этого является гораздо более длинным ответом, чем это оправдано здесь. Я бы предложил сделать это поэтапно, так как в Интернете есть ресурсы о том, как работать с самоподписанным сертификатом SSL в Android и iOS, как на сервере, так и на стороне клиента. В моей книге « Безопасность приложений для платформы Android» , опубликованной O'Reilly, также есть полный обзор.

SSL имеет двухстороннюю аутентификацию, как уже упоминалось другими комментаторами. Но я не думаю, что вы даже должны пытаться аутентифицировать клиента, например приложение. Вы только аутентифицируете пользователя (владельца ресурса в терминах Oauth), а не агента или клиента.

Это факт, что мобильные приложения не могут хранить никаких секретов. Поэтому никогда не ставьте сертификаты / пароли на устройство. Типичным плохим примером было бы сохранить имя пользователя и пароль в каком-то системном хранилище ключей, таком как брелок IOS. Если пользователь приложения не устанавливает пароль на телефоне, все хранилище ключей сохраняется в виде обычного текста, и каждый может сбрасывать всю информацию. Вставить сертификат в приложение почти так же плохо, как в отличие от сервера, мобильный телефон не заблокирован в компьютерной комнате. Люди теряют их.

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

Oauth 2.0 Неявный поток предназначен для решения этой проблемы. Однако, это далеко не идеально. И есть некоторые фундаментальные проблемы с Oauth 2.0 spec. В частности, для реализации этого потока приложение должно использовать UIWebView (встроенный браузер), который сам по себе может быть небезопасным и плохой пользовательский интерфейс. Таким образом, это в значительной степени устраняет все потоки, основанные на перенаправлении. Единственное хорошо известное приложение, использующее перенаправление OAuth 2, – это facebook, и его сделано плохо.

OAuth 2.0 Resource Owner – один из вариантов. Благодаря этому потоку ваш уровень безопасности всей системы может быть таким же высоким, как и решение B2C – решение для онлайн-банкинга на основе браузера. Это означает, что любой пользователь с паролем имени пользователя сможет получить доступ к ресурсам на сервере – такой же уровень безопасности для решения на базе браузера.

Тем не менее, вам все равно нужно быть осторожным, как уже упоминалось ранее, спецификация OAuth 2 имеет некоторые фундаментальные проблемы: в этом случае вы не можете следовать ее спецификации для реализации логики обновления токена, которая обычно включает использование обновляющего токена – который можно рассматривать как реализацию OAuth 2 Google. Затем этот токен становится тайной – побеждает цель использования OAuth.

Одним из способов является автоматическое обновление маркера на основе последнего действия.

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

Вот почему банки платят миллионы за решение своего мобильного банкинга, и все же они по-прежнему терпят неудачу ( http://hothardware.com/News/Mobile-Banking-Apps-for-iOS-Vulnerable-to-Man-in-the-Middle-Attacks / ) 😉

Использовать аутентификацию клиента с помощью SSL или просто накладывать собственную аутентификацию клиента (имя пользователя / пароль, токен и т. Д.) Поверх SSL-аутентификации сервера.

(Edit: Перемещение комментария здесь, так как оно не подходит в качестве комментария)

Чтобы разработать немного, любая информация аутентификации должна быть сохранена или введена в приложение. Если вы каждый раз вводите пароль, вам не нужно его сохранять, но это явно неудобно. Вы можете зашифровать его с помощью определенного для устройства ключа, чтобы он не был виден на корневых устройствах. С помощью закрытого ключа вам необходимо либо защитить его с помощью введенного пользователем пароля (см. Выше), либо защитить его системой. Это доступно только с Android 4.0 (ICS) с открытым API-интерфейсом для KeyChain хранилища системы – класса KeyChain . В этом случае пользователю необходимо разблокировать (используя шаблон / пароль или PIN-код) для доступа к хранилищу ключей.