Как реализовать восстановление доступа к профилю пользователя в приложении
Что проверяют
Умеете ли вы описать процесс целиком: основной сценарий, альтернативные ветки, требования безопасности и то, что увидит пользователь. Одного «пришлём письмо со ссылкой» мало. Следом спрашивают, что делать, если у человека нет доступа ни к почте, ни к телефону, и как не выдать, зарегистрирован ли адрес.
Как отвечать
Отвечайте так, как оформили бы требования:
- каналы: ссылка на почту, код по SMS или пушем, резервные коды, запасной контакт, ручное восстановление через поддержку с проверкой личности. Контрольные вопросы современные рекомендации (NIST SP 800-63B) использовать не советуют: ответы легко узнать или подобрать;
- основной сценарий: ввод логина, единый ответ «если аккаунт существует, мы отправили инструкцию», одноразовый токен, новый пароль, завершение всех активных сессий, уведомление на известные каналы;
- требования к токену: криптостойкий случайный, в базе хранится его хэш, срок жизни от 15 минут до часа, одноразовый, новый запрос отзывает предыдущий;
- защита от злоупотреблений: лимит запросов на адрес и IP, капча после нескольких попыток, лимит ввода кода (шесть цифр без ограничения попыток перебираются), защита от накрутки платных SMS;
- второй фактор: сброс пароля его не отключает, восстановление самого второго фактора оформляется отдельным, более строгим процессом;
- артефакты: BPMN или диаграмма последовательности, use case с альтернативными потоками, контракт API на запрос и подтверждение сброса, события для аудита.
Добавьте метрики: доля успешных восстановлений, время до входа, число обращений в поддержку. Они покажут, где процесс теряет людей.
Где спотыкаются
Дают разные ответы на существующий и несуществующий адрес. Так любой может проверить, зарегистрирован ли человек в сервисе.
Описывают только счастливый путь. Истёкший токен, повторный клик по старой ссылке, заблокированный аккаунт и потерянный доступ к почте остаются без поведения, и разработчики решают за аналитика.
Забывают про последствия сброса: сессии не завершаются, и злоумышленник, угнавший аккаунт, остаётся внутри даже после смены пароля владельцем.