При проверке механизма сброса пароля как оценить, достаточно ли непредсказуем токен восстановления?
Нужно проверить, что токен создаётся криптографически стойким генератором случайных значений, имеет достаточную длину и не выводится из предсказуемых данных: идентификатора пользователя, времени или последовательного номера. Практическое доказательство включает анализ способа генерации, сбор серии токенов и попытку их подбора или восстановления закономерности.
Одной большой длины недостаточно: предсказуемый генератор может создавать длинные, но угадываемые значения. Дополнительно проверяют срок действия, одноразовость и ограничение числа попыток, поскольку эти свойства уменьшают окно атаки, но не заменяют непредсказуемость.
Механизмы восстановления пароля появились как способ вернуть пользователю доступ без раскрытия старого пароля и без ручного вмешательства администратора. Первые реализации часто связывали токен с данными пользователя или временем создания, что упрощало реализацию, но создавало возможность угадать или вычислить секрет.
Современный подход разделяет идентификацию запроса и секрет авторизации: ссылка может содержать идентификатор записи, но право на сброс подтверждается отдельным случайным токеном. Такой токен должен быть практически непредсказуемым для атакующего.
Если злоумышленник угадает действующий токен, он сможет установить новый пароль без знания текущего. Последствия включают захват учётной записи, доступ к персональным данным и дальнейшее использование доверия к скомпрометированной учётной записи.
Тестировщик должен выяснить, как токен создаётся, сколько он живёт, связан ли с конкретной учётной записью и можно ли использовать его повторно. Важно проверять не только внешний вид значения, но и серверную логику: случайная строка может оказаться предсказуемой из-за слабого источника случайности или ошибочного преобразования.
Сначала анализируют реализацию и архитектуру. Токен должен формироваться криптографически стойким генератором случайных чисел, иметь достаточную энтропию и передаваться без преобразований, снижающих пространство возможных значений. Использование времени, счётчика, хеша открытых пользовательских данных или обычного псевдослучайного генератора является подозрительным.
Затем получают серию токенов для разных запросов и пользователей. Ищут последовательность, повторения, корреляцию с временем, идентификатором учётной записи или порядком выдачи. Статистический тест сам по себе не доказывает криптографическую стойкость, но помогает выявить явные закономерности; окончательный вывод делают по алгоритму генерации и размеру пространства поиска.
Проверка перебором должна проводиться только в тестовой среде или на специально подготовленной учётной записи. Нужно определить, ограничивает ли система частоту попыток, но не считать наличие блокировки доказательством безопасности: даже медленный перебор опасен, если токен имеет малую энтропию.
Токен должен иметь ограниченный срок действия, быть одноразовым и инвалидироваться после успешной смены пароля или повторного запроса восстановления. Эти меры сокращают последствия утечки, однако не исправляют слабую генерацию: пока токен действителен, его угадывание остаётся атакой.
Нужно также проверить защиту от утечки токена через журналы, аналитические системы, историю браузера и сторонние ресурсы. Даже стойкий токен теряет ценность, если его можно получить из открытого лога или повторно использовать после раскрытия.
В тестовом окружении токены восстановления выглядели длинными, но отличались главным образом временем создания и идентификатором пользователя. Рассматривались два варианта: ограничиться снижением срока действия токена или заменить механизм генерации.
Сокращение срока действия было проще внедрить и уменьшало окно атаки, но не устраняло возможность предсказания и не защищало от быстрых попыток подбора. Замена генерации требовала изменения сервиса и миграции текущих токенов, зато устраняла первопричину.
Выбрали криптографически стойкие случайные токены, одноразовое использование, немедленную инвалидизацию старых токенов и ограничение частоты запросов. После этого повторная проверка не выявила закономерностей, а старые токены перестали работать; результат был принят как исправление, потому что были закрыты и проблема предсказуемости, и последствия возможной утечки.
1. Достаточно ли проверить, что токен содержит много символов?
Нет. Важна не длина представления, а энтропия — количество реально непредсказуемых вариантов. Длинный токен, составленный из времени, идентификатора и небольшого случайного суффикса, может иметь намного меньше вариантов, чем кажется по числу символов.
Нужно установить источник случайности, способ генерации и отсутствие сокращения пространства значений при кодировании. Например, преобразование случайных байтов в текст безопасно только при сохранении всей исходной информации и отсутствии последующего усечения.
2. Делает ли ограничение числа попыток слабый токен безопасным?
Нет. Ограничение попыток снижает скорость перебора, но не повышает непредсказуемость токена. При большом сроке действия, утечке информации о структуре значения или наличии множества параллельных точек проверки атака всё ещё может быть успешной.
Rate limiting является дополнительным контролем. Основным требованием остаётся достаточная энтропия, а срок действия и ограничение попыток должны уменьшать вероятность успешного использования украденного или случайно угаданного токена.
3. Почему одноразовость важна, если токен уже криптографически стойкий?
Стойкость защищает от угадывания, но не от раскрытия токена. Он может попасть в журнал, историю браузера, отчёт мониторинга или быть перехвачен через заражённое устройство.
Одноразовость ограничивает последствия такой утечки: после успешного использования токен больше не даёт право на сброс. Поэтому тестировщик должен отдельно проверить повторное открытие ссылки, повторную отправку формы и действие старого токена после выпуска нового.