Сброс пароля: что хранить, что не хранить

Механизм сброса пароля опирается на раздельное хранение двух сущностей: постоянного пароля пользователя и временных токенов восстановления доступа. Ошибки в проектировании этой части системы приводят к компрометации учетных записей даже при использовании устойчивых хэш-функций из библиотеки наподобие password-hash в JavaScript.

Пароль в системе никогда не хранится в исходном виде. Для этого используется криптографическое хэширование с солью. Библиотека password-hash применяется для генерации необратимого представления пароля, при котором:

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

Хранимое значение в базе данных включает только результат хэширования и параметры алгоритма (соль, параметры итераций). Сам пароль и его промежуточные формы не сохраняются ни в логах, ни в кэше, ни в резервных копиях в открытом виде.

Структура хранения учетной записи

Минимальная модель пользователя для корректной работы сброса пароля включает:

• идентификатор пользователя;
• хэш пароля;
• параметры хэширования;
• метаданные безопасности (дата смены пароля, версия алгоритма);
• статус учетной записи.

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

Токен сброса пароля

Процесс восстановления доступа основывается на временном токене. Этот токен выполняет роль одноразового ключа и обладает ограниченным временем жизни.

Генерация токена выполняется с использованием криптографически стойкого генератора случайных значений. Важно различать токен в исходном виде и его хранимое представление.

Что хранится в базе данных

В системе не допускается хранение токена в открытом виде. Вместо этого сохраняется его хэш:

• hash(token);
• идентификатор пользователя;
• время создания;
• время истечения;
• статус использования (активен / использован).

Такой подход снижает риск компрометации в случае утечки базы данных. Даже при доступе к таблице восстановления невозможно использовать токен напрямую.

Жизненный цикл токена сброса

1. Запрос на восстановление доступа инициирует генерацию токена.
2. Токен передается пользователю через канал связи (обычно email).
3. В базе сохраняется только его хэш и метаданные.
4. При использовании токен сверяется через повторное хэширование.
5. После успешного применения токен помечается как использованный.

Повторное использование одного и того же токена исключается. Дополнительная генерация нового токена инвалидирует предыдущие записи.

Ошибки хранения, ведущие к уязвимостям

На практике распространены ошибки, связанные с неверным выбором данных для хранения:

• сохранение токена восстановления в открытом виде;
• отсутствие ограничения срока действия;
• хранение пароля или его части в логах;
• отсутствие привязки токена к пользователю;
• повторное использование токенов без инвалидирования.

Каждая из этих ошибок снижает эффективность даже корректно реализованного хэширования паролей через password-hash.

Связь сброса пароля и хэширования паролей

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

После установки нового пароля:

• старый хэш заменяется новым значением;
• все активные токены сброса инвалидируются;
• фиксируется событие изменения пароля.

Это предотвращает возможность использования устаревших ссылок для восстановления доступа.

Политика хранения временных данных

Временные данные сброса пароля должны иметь строгие ограничения:

• автоматическое удаление по истечении срока жизни;
• хранение только хэшированных значений;
• минимальный набор метаданных;
• отсутствие пересечения с основным паролем пользователя.

Дополнительно применяется ограничение количества активных токенов на одного пользователя, что снижает риск атак перебора и повторной генерации ссылок.

Безопасная интеграция с password-hash

При использовании библиотеки password-hash в JavaScript логика сброса пароля должна учитывать:

• неизменность алгоритма хэширования для одной учетной записи до миграции;
• возможность проверки версии хэша при авторизации;
• повторное хэширование нового пароля с актуальными параметрами;
• отсутствие прямого взаимодействия токена сброса с хэшем пароля.

Токен восстановления никогда не используется как часть пароля и не участвует в его хэшировании. Это два независимых криптографических объекта с разными жизненными циклами.

Разделение ответственности в хранилище

Корректная архитектура предполагает разделение таблиц или коллекций:

• данные учетной записи пользователя;
• хэши паролей;
• временные токены восстановления.

Объединение этих сущностей в одну структуру увеличивает поверхность атаки и усложняет контроль доступа.