Вопрос или проблема
Я работаю над приложением для iOS, и его система входа, похоже, не совсем безопасна, но я не знаю достаточно, чтобы быть уверенным.
Пропустив создание аккаунта, при первом входе пользователь отправляет свое имя пользователя и хешированный пароль на сервер, чтобы получить токен, с помощью которого он может выполнять остальные вызовы API.
Это кажется приемлемым, но пользователю предлагается возможность активировать биометрическую аутентификацию в настройках приложения, и здесь я не уверен в безопасности реализации.
Чтобы активировать эту функцию, пользователь доказывает право собственности на свой телефон, используя Face ID или Touch ID.
Если это сделано успешно, приложение делает вызов API, отправляя следующую информацию на сервер, который активирует биометрическую аутентификацию для этого аккаунта пользователя:
- имя пользователя (избыточно)
- сессионный токен
- внутренний идентификатор устройства
- идентификатор уведомлений (APNS) устройства
С этого момента, чтобы получить токен (войти), приложение делает другой вызов API (не стандартный вызов имя пользователя/пароль), где отправляются только имя пользователя и два упомянутых идентификатора устройства (очевидно, это делается только после успешного использования биометрической аутентификации на телефоне).
Это безопасно?
Не кажется невероятным, что кто-то может выяснить имя пользователя и эти два идентификатора устройства, чтобы получить доступ.
Если это небезопасно, каков должен быть правильный подход? Как, например, это делают банковские приложения?
Я не смог найти ответ на эти вопросы с помощью гугления и т. д.
Вы все еще используете сессионный токен, который, если он реализован правильно, уже является безопасным.
Все, что делает Face/Touch ID, — это добавляет вторичный фактор на стороне клиента, который не позволяет использовать сессионный токен, пока аутентификация не завершена.
Ответ или решение
Конечно, давайте рассмотрим вашу реализацию биометрической аутентификации и проанализируем ее безопасность.
Текущая реализация
Ваше текущее решение включает в себя следующие ключевые аспекты:
-
Активация биометрической аутентификации:
- Пользователь подтверждает владение устройством с помощью Face ID или Touch ID.
- При успешной аутентификации происходит API-запрос для активации биометрической аутентификации, передавая:
- Имя пользователя
- Сессионный токен
- Внутренний идентификатор устройства
- Идентификатор уведомления (APNS)
-
Авторизация после активации:
- Для получения нового токена используется другой API-запрос, в котором отправляются только имя пользователя и два идентификатора устройства, выполненные после успешного прохождения биометрической аутентификации.
Оценка безопасности
Плюсы:
- Использование сессионных токенов: Они позволяют избежать повторной отправки учетных данных (логин и пароль) после первоначальной аутентификации.
- Биометрическая аутентификация: Это добавляет дополнительный уровень безопасности на стороне клиента.
Минусы:
-
Уязвимость к раскрытию идентификаторов устройства:
- Если злоумышленник каким-то образом узнает имя пользователя и идентификаторы устройства, он сможет попытаться получить токен, не обладая фактическими данными для аутентификации пользователя.
-
Отсутствие дополнительной проверки:
- Указанная схема не использует дополнительные механизмы проверки, которые могли бы предотвратить использование украденных идентификаторов.
Рекомендации по улучшению безопасности
-
Использование двухфакторной аутентификации (2FA):
- Рассмотрите возможность использования 2FA, где пользователю будет предложено ввести временный код, отправленный на зарегистрированный номер телефона или электронную почту, после успешного прохождения биометрической аутентификации.
-
Узнавание устройства и сессии:
- Помещайте ограничения на доступ по сессионному токену. Например, проверьте, что вызовы к API происходят только с одного и того же устройства и для активной сессии.
-
Шифрование и безопасная передача данных:
- Все данные, передаваемые между клиентом и сервером, должны быть строго шифрованы (например, с использованием TLS). Дополнительно применяйте механизмы, такие как HMAC, для защиты данных и проверки их целостности.
-
Регулярное обновление токенов:
- Установите срок действия сессионных токенов и проводите механизмы обновления токенов, чтобы снизить риск их компрометации.
-
Мониторинг и оповещение о несанкционированном доступе:
- Внедрите механизмы мониторинга, чтобы быстро реагировать на подозрительную активность, например, несанкционированные попытки входа или сессии из неожиданных регионов.
Как это реализуют банки
Банковские приложения зачастую используют многоуровневую аутентификацию, которая может включать:
- Биометрическую аутентификацию.
- Отправку одноразовых паролей (OTP) через SMS или приложения для аутентификации.
- Постоянную проверку рисков при каждой транзакции (например, отслеживание местоположения пользователя).
Заключение
Хотя ваше текущее решение лучше, чем обычный ввод пароля, стоит пересмотреть его с точки зрения упомянутых выше рисков и ввести дополнительные меры защиты. Обсудите эти варианты с вашей командой разработки для повышения общей безопасности приложения.