Аутентификация — первая линия защиты мобильного приложения. Если она реализована с ошибками, злоумышленник может получить доступ к аккаунтам, данным пользователей и внутренним API даже без сложного взлома. Разберём, где чаще всего допускают промахи и как их избежать.
Хранение токенов в небезопасном виде
Одна из самых частых проблем — сохранение access token, refresh token или пароля в обычном SharedPreferences, логах или локальной БД без защиты. На Android и iOS для этого есть безопасные механизмы: Keystore и Keychain.
Что важно: токены не должны храниться в открытом виде и попадать в debug-логи.
Слабая серверная проверка
Ошибка не только на стороне клиента. Даже если приложение выглядит защищённым, сервер может доверять данным, пришедшим с устройства. Например, принимать поддельные идентификаторы сессий, не проверять срок жизни токена или не инвалидировать refresh token после выхода.
Безопасная схема: вся критичная проверка должна происходить на backend, а не в мобильном клиенте.
Отсутствие MFA там, где она нужна
Для банковских, корпоративных, медицинских и админ-приложений одного пароля уже недостаточно. Если компрометирован пароль, злоумышленник входит без препятствий.
Решение: многофакторная аутентификация — TOTP, push-подтверждение, аппаратные ключи или биометрия как второй фактор, но не как единственный.
Небезопасная работа с биометрией
Face ID и Touch ID удобны, но не заменяют полноценную аутентификацию. Частая ошибка — считать успешную локальную биометрическую проверку доказательством личности на сервере.
Биометрия должна лишь разблокировать локально защищённый секрет, а не подменять проверку учётных данных.
Уязвимые механизмы восстановления доступа
Сброс пароля через SMS без дополнительной защиты, слабые security questions или предсказуемые OTP-коды — типичный путь к захвату аккаунта.
Нужны: ограничение попыток, короткий TTL кодов, защита от brute force, уведомления о сбросе и анализ подозрительной активности.
Отсутствие защиты API-канала
Если приложение не проверяет TLS корректно, не использует certificate pinning там, где это оправдано, и передаёт токены в небезопасных запросах, появляется риск MITM-атак.
Минимум: только HTTPS, актуальные сертификаты, отказ от устаревших протоколов и аккуратная работа с сетевым стеком.
Проблемы с сессиями
Долгоживущие токены, отсутствие ротации refresh token, неограниченное число активных сессий — всё это увеличивает окно атаки.
Хорошая практика: короткоживущий access token, ротация refresh token, отзыв сессий и контроль устройств пользователя.
Что проверить разработчику и команде безопасности ✅
- Где и как хранятся токены
- Есть ли защита от reverse engineering и утечек в логах
- Проверяется ли всё критичное на сервере
- Настроены ли rate limiting и защита от credential stuffing
- Безопасен ли процесс регистрации, входа и восстановления доступа
- Есть ли мониторинг аномальных входов
Небезопасная аутентификация в мобильных приложениях — это не одна ошибка, а обычно цепочка мелких недоработок. Чем раньше провести аудит auth-логики, API и хранения секретов, тем ниже риск взлома и утечки данных. 🛡️
📚 Посмотрите подборку каналов про IT — там регулярно выходят полезные материалы по безопасности, разработке и инфраструктуре.