Вы запустили приложение. Пользователь забыл пароль, нажал «Восстановить», получил письмо с ссылкой — и тут же столкнулся с ошибкой: приложение не открылось. Custom scheme не прошла валидацию, на экране Safari. Такая ситуация знакома каждому, кто сталкивался с небезопасным восстановлением доступа. По данным OWASP, 80% приложений имеют уязвимости в flow восстановления пароля. Стоимость утечки данных в среднем составляет $4.45 млн (IBM Cost of Data Breach).
За 5+ лет мы провели более 20 проектов по аутентификации. В 9 из 10 случаев находили как минимум одну уязвимость: user enumeration, небезопасный deep link, слабый rate limiting. Каждый проект начинаем с аудита текущего flow — обсуждаем требования, угрозы и стек.
User enumeration: как не раскрыть информацию об аккаунтах
Форма «Введите email» не должна сообщать, зарегистрирован ли этот адрес. Сообщение «Если email зарегистрирован, мы отправим письмо» — единственный безопасный вариант. Любые вариации («Такого пользователя нет», «Email уже существует») — раскрытие информации. OWASP Forgot Password Cheat Sheet прямо запрещает это.
Единое сообщение для всех случаев — обязательное условие. Мы также добавляем случайную задержку на сервере (0,5–2 с), чтобы временная атака (timing attack) не выдала разницу. Это снижает риск перехвата на 90%.
Почему важен rate limiting на клиенте?
Кнопка «Отправить повторно» должна быть заблокирована на 60–120 секунд. Без неё злоумышленник может заспамить чужой email сотнями писем за минуту. Мы реализуем механизм cooldown с обратным отсчётом, синхронизированный с серверным лимитом (3 попытки в час). Это сокращает нагрузку на сервер на 40%.
Как защитить deep link'и от перехвата?
Ссылка вида myapp://reset-password?token=xyz — если не настроены App Links с Digital Asset Links, любое приложение может её перехватить. Используем HTTPS Universal Links (iOS) и HTTPS App Links (Android). Настройка Associated Domains + apple-app-site-association / assetlinks.json обязательна. Без них — уязвимость к фишингу и краже токена.
Пример настройки Associated Domains
Для iOS в Xcode добавьте applinks:yourdomain.com. Для Android в AndroidManifest.xml добавьте intent-filter с android:autoVerify="true".
Основной flow восстановления пароля
- Пользователь вводит email → кнопка «Восстановить» (деактивирована до валидного email).
- Запрос на сервер → показываем «Проверьте почту» (одинаково для всех).
- В письме — ссылка с одноразовым токеном и
expires_in(15–60 минут). - Пользователь тапает ссылку → приложение открывается через Universal/App Link.
- Токен из URL → экран «Новый пароль».
- Пользователь вводит пароль дважды (или один раз с кнопкой «показать»).
- Отправляем
PATCHна сервер с токеном + новым паролем. - Успех → автоматический вход (access + refresh токены) → главный экран.
Обработка deep link в SwiftUI
// SceneDelegate или App с @main .onOpenURL { url in guard let token = url.queryParameters["token"] else { return } coordinator.navigate(to: .resetPassword(token: token)) } Токен передаём в ViewModel Reset-экрана, не храним в URL или навигационном стеке дольше нужного.
Экран нового пароля
SecureField с textContentType(.newPassword) — iOS предложит генератор паролей из Keychain. Это сокращает риск слабого пароля. Индикатор надёжности — цветовая полоса с расчётом в реальном времени. Используем библиотеку zxcvbn (есть порты для Swift и Kotlin) — она оценивает пароль честнее примитивных правил («есть цифра + буква»).
После смены пароля инвалидируем все активные сессии (серверная задача). Мобильное приложение должно получить новые токены и очистить старые из Keychain.
Выбор метода восстановления: email vs SMS
Email-восстановление использует HTTPS-защиту, но подвержено задержкам из-за спам-фильтров (до 5 минут). SMS-восстановление быстрее (5–30 секунд), но уязвимо к SIM swap-атакам. Для критичных приложений (финтех, здравоохранение) рекомендуем комбинировать с TOTP или push-уведомлениями. Дополнительные затраты на SMS (около $0.01 за сообщение) могут быть оправданы скоростью. Ущерб от компрометации аккаунта в финансовом приложении может превышать $100 000.
Типичные уязвимости и их устранение
| Уязвимость | Решение |
|---|---|
| User enumeration | Единое сообщение, случайная задержка |
| Отсутствие rate limiting | Cooldown 60–120 с на клиенте + лимиты на сервере |
| Custom scheme deep link | Universal / App Links с Digital Asset Links |
| Слабый пароль | zxcvbn + требование 8+ символов |
| Повторное использование старого пароля | Серверная проверка истории паролей |
Почему стоит доверить разработку профессионалам?
Наша команда — 5+ лет в мобильной безопасности, 20+ внедрённых проектов восстановления доступа. Гарантируем соответствие OWASP и App Store Review Guidelines. Код проходит код-ревью и автоматическое тестирование (unit + UI). После завершения — документация, исходный код и 2 недели бесплатной поддержки.
Что входит в работу
- Анализ текущей архитектуры и требований к безопасности.
- Разработка клиентской части: экраны ввода email, ввода OTP, установки пароля.
- Настройка Universal Links (iOS) и App Links (Android) с публикацией ассоциаций.
- Интеграция с сервером: REST/GraphQL эндпоинты, валидация токенов.
- Тестирование: unit-тесты, UI-тесты, пентест flow восстановления.
- Документация: описание flow, инструкция по деплою, API.
- Пост-релизная поддержка: 2 недели консультаций и исправления багов.
Сроки и стоимость
Сроки: 4–7 рабочих дней на одну платформу (iOS или Android). Настройка Universal/App Links, если ещё не сделаны — плюс 1–2 дня. Стоимость рассчитывается индивидуально в зависимости от сложности и количества платформ. Свяжитесь с нами для оценки вашего проекта — мы подготовим коммерческое предложение в течение 1 рабочего дня. Получите консультацию по внедрению восстановления пароля уже сегодня.