Письмо с паролем доказывает обратимость, а не схему хранения

Сервис, который присылает текущий пароль пользователя по электронной почте, доказал одну вещь: он может получить этот секрет в том виде, который способен отправить. Он не доказал, какой столбец, алгоритм или библиотека его создали. Это различие важно, потому что находка реальна, а вывод, который из неё делают, обычно слишком конкретен. Обратимость где-то на пути — это механизм; предполагаемый формат хранения — нет.

Держите доказательства на этом уровне, и остальная часть разбора останется точной.

Что доказывает возврат старого секрета

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

Обратите внимание и на промежуточный случай: сохранённый зашифрованный блок с ключом, который держит приложение, на практике обратим, хотя слово зашифрованный в отчёте звучит успокаивающе.

Почему это находка о проектировании, а не карта хранения

Письмо доказывает восстановимость и не определяет точную схему. Это может быть открытый текст, детерминированное шифрование, процедура запутывания от поставщика или отдельное хранилище учётных данных, используемое только для восстановления. Разные части продукта часто используют разное хранение. Приписывать алгоритм на основании одного письма — это тип утверждения, который рассыпается на следующей встрече.

Сказать можно более узко и более полезно: этот путь может восстановить секрет, поэтому продукт не может утверждать, что восстановимых учётных данных не существует. Всё остальное требует доказательств оператора.

Стройте сброс вокруг авторизации

Сброс решает другую задачу: доказать, что заявитель вправе выбрать новый пароль. Руководство OWASP на этот счёт описывает безопасно сгенерированные одноразовые токены или коды с подходящим сроком действия и рассматривает этап запроса как то, что нужно защищать от перебора и наплыва. Неаутентифицированный запрос не должен сам по себе менять учётную запись. Проверьте авторизацию, прежде чем принимать замену, и сделайте токен непригодным после одного успешного использования.

Почтовый канал — часть модели безопасности. Обладание именем учётной записи ничего не доказывает, а поток сброса, раскрывающий, существует ли учётная запись, даёт злоумышленнику справочник для работы.

Аннулируйте то, что защищал пароль

Смена пароля не прекращает автоматически доступ, который он давал. Активные сеансы VPN, запомненные устройства и токены, выданные сервером, могут иметь собственное поведение при аннулировании. Сознательно решите, какие из них должны завершиться, и проверьте, что реализация это делает, потому что пользователь, который полагает, что сброс разлогинил его везде, часто ошибается. Запишите это решение вместе с потоком.

Для операторов: задокументируйте, какой компонент проверяет запрос, какой меняет учётные данные и как обрабатываются связанные сеансы. Для пользователей: защищайте законный канал восстановления и считайте подозрительным любое сообщение, которое возвращает пароль.

Точная оценка коротка: что доказывает сообщение, что остаётся неизвестным и заменяет ли восстановление доступ с помощью контролируемого процесса.