Безопасная аутентификация в мобильном приложении

Я ищу способ аутентификации пользователей моего мобильного приложения безопасным способом. Мобильное приложение является чистым JS-приложением и использует ионный каркас (и, следовательно, кордову). Приложение будет связываться только с нашим сервером через REST API. Требования следующие:

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

Что я нашел:

Использование OAuth 2

OAuth 2 предоставляет долговременный токен, называемый "токен обновления". Я хотел бы использовать его с установкой даты истечения срока годности примерно на один год.

Однако, похоже, нет сильного меканизма, чтобы защитить этот токен. Действительно, как упоминание в Jamsheed Kamarudeen прокомментировал этот ответ qaru.site/info/16809/..., если токены обновления, идентификатор клиента и секретный идентификатор украдены (с помощью обнюхивания или взятия их непосредственно из устройство), злоумышленник сможет иметь неограниченный доступ к учетной записи пользователя... без каких-либо изменений, AFAIK, чтобы это произошло.

Обнюхивание может быть затруднено, потому что, очевидно, все данные будут отправляться через безопасное соединение (SSL), но это все еще возможно, и с моей точки зрения это должно управляться. Что касается второго типа атаки, "принимая их непосредственно с устройства", каждое решение, которое я видел, касается хранения данных (токенов или файлов cookie) в локальном хранилище или в cookie браузера (это сообщение, например Использование OAuth2 в веб-приложении HTML5). Даже если пример из этой публикации содержит рекомендации по хранению хэша токена обновления, я не могу понять, в чем его цель, поскольку, как упоминает комментарий Мати Цицерона, это не остановит злоумышленника возможность получить токен доступа и, в моем случае, неограниченный доступ к учетной записи пользователя.

Кроме того, из того, что я вижу, localstorage и файлы cookie слишком легко читаются. Это достаточно или я должен использовать собственное безопасное хранилище Android/iOS? Даже локального локального хранилища кажется недостаточно (https://github.com/phonegap/phonegap/wiki/Platform-Security).

Использование Spring безопасности

Серверная сторона будет реализована благодаря Spring. Меканизм, обеспечиваемый Spring -security, кажется лучше, чем OAuth 2, в отношении шаблона помнить меня (http://jaspan.com/improved_persistent_login_cookie_best_practice). Однако, как я понял, конечный пользователь не сможет дважды войти в приложение (скажем, его персональный мобильный и его профессиональный). Я признаю, что это не огромная проблема, но, тем не менее, она не идеальна. Самое главное, в конце мы все еще имеем проблемы с безопасностью хранения файлов cookie/токенов.

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

Мой вопрос: как вы можете видеть выше, я не нашел одного безопасного mecanism для настройки этого процесса "автоматического входа" в веб-мобильное приложение. Что мне нужно настроить? У вас есть другой меканизм, чем те, которые я нашел, чтобы представить меня?

Ответ 1

Помните о последствиях

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

для OAUTH или не

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

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

SSL

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

Компромисс на тему "запомнить меня"

Что вы можете сделать, чтобы улучшить ситуацию:

Вы можете аннулировать запрос клиента на его аутентификацию, если ваш сервер отмечает изменения отпечатка браузера, но сеанс остается тем же. Это может произойти из-за плохо настроенных прокси-серверов, но немногие из них уже существуют. И в худшем случае пользователю необходимо снова войти в систему.
вы можете использовать IP-адрес для местоположений GEO (например, в стране), и если вы заметите изменение страны из последнего соединения без повторного аутентификационного соединения: не соблюдайте память и не требуйте надлежащая проверка подлинности.

Защитить файлы cookie

Вы можете хранить файлы cookie в браузере как "безопасные": это означает, что браузер отправит cookie только на сервер, если он подключен к https-соединению
Вы также можете установить cookie для httponly: это заставляет браузер отказываться от доступа к файлу cookie с javascript на стороне клиента (и все, что он сделает, это отправить его на сервер.
Вы можете одновременно установить и httponly и secure... (что вы хотите).

Ответ 2

Независимо от технического решения, которое вы, наконец, выберете, останется неизменным:

не о мобильном приложении, вся архитектура клиент/сервер
Невозможно сохранить логины без риска для безопасности.
более безопасный способ - зашифровать его на устройстве
Лучше всего использовать способ использования банковских приложений: no persistance
однако два фактора sigin довольно безопасны.
Абсолютного ответа на этот вопрос нет, это просто выбор наилучшего выбора между этими соображениями и потребностями вашего приложения.

ИЗМЕНИТЬ

О encryt учетных данных

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

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

Ответ 3

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