Инструменты разработчика · Генератор UUID
Является ли случайный UUID безопасным для сброса пароля или токена сеанса?
· Почему это важно
uuid криптография API-интерфейс браузера
UUID версии 4 из CSPRNG имеет много энтропии, так почему же эксперты по безопасности до сих пор недовольны токенами UUID? Этот пост отделяет вопрос энтропии от вопроса дизайна.
Ссылка сброса, использующая UUID строки — распространенный ярлык и две совершенно разные причины, по которым она может быть небезопасной.
Распространенный ярлык: используйте идентификатор строки пользователя UUID в качестве токена для сброса пароля. В таблице есть столбец uuid; он уникален; трудно догадаться (если это v4). URL — это /reset? токен=550e8400-e29b-41d4-a716-446655440000. Эксперт по безопасности немедленно отклоняет его не потому, что UUID слабый, а потому, что он объединяет две проблемы, которые должны быть независимыми. Строка UUID стабильна и обычно общедоступна (в URL-адресах, API, журналах). Токен сброса должен быть одноразовым и секретным. Повторное использование строки UUID в качестве токена означает, что личность пользователя и его учетные данные для сброса имеют одно и то же значение, а срок действия учетных данных сохраняется навсегда, а не истекает. Злоумышленник, знающий идентификатор пользователя, может выполнить сброс. Пользователь, скопировавший ссылку сброса пять лет назад, все еще может ее использовать. Это недостатки дизайна, а не недостатки энтропии.
Проверка энтропии: 122 случайные биты — почему сгенерированный CSPRNG v4 невозможно угадать методом перебора
Проверка случайности необходима, но недостаточна. Версия 4 резервирует четыре бита версии и два бита варианта, оставляя 128 - 4 - 2 = 122 случайные позиции, когда реализация заполняет другие поля случайным образом. Этот вывод ничего не говорит об истечении срока действия, хранении или авторизации. Проверка генератора спрашивает, пришли ли эти поля из CSPRNG, а не из Math.random или временной метки. ToolAcre удовлетворяет этой границе генератора. Проверка конструкции остается специфичной для приложения: для сброса учетных данных требуется отдельный жизненный цикл, одностороннее сохраненное представление, аннулирование после успешного использования и истечение срока действия, выбранное из политики риска службы. Повторное использование идентификатора постоянной записи пользователя не позволяет выполнить такое разделение, даже если идентификатор был сгенерирован безопасным образом.
Проверка генератора: где на самом деле терпят неудачу токены UUID — генерация на основе Math.random, временные метки v1 и адреса MAC, а также предсказуемые начальные числа
Проработанный пример: схема сброса пароля, которая терпит неудачу, а затем проходит три проверки. Не проходит проверку энтропии: сервер выдает токен сброса через Math.random(), упакованный как v4 UUID. Злоумышленник наблюдает за тремя токенами и предсказывает четвертый. Не проходит проверка генератора: сервер использует v1 UUID в качестве токена сброса, включая метку времени создания и адрес MAC в значении. Злоумышленник считывает временную метку, узнает, когда был выполнен сброс, и сужает окно поиска. Проходит проверку энтропии, но не проходит проверку конструкции: сервер использует UUID версии 4 из crypto.getRandomValues, но сохраняет его в виде обычного текста в базе данных и не устанавливает срок действия. Злоумышленник, взломавший базу данных, считывает токены сброса и использует их для сброса учетных записей через несколько недель. Эти три проверки независимы; вы должны пройти все три.
Проверка дизайна: идентификатор против учетных данных — почему повторное использование первичного ключа записи в качестве секрета объединяет две вещи, которые должны вращаться независимо
Схема токена сброса, которая проходит проверку энтропии и генератора, но не проходит проверку конструкции (без хэша, без срока действия, без аннулирования для каждого использования), по-прежнему уязвима. Обработка токена на стороне сервера: когда пользователь запрашивает сброс пароля, генерируется новый случайный токен (не строка UUID) из crypto.getRandomValues. Сохраните одностороннее представление, а не представленное значение, установите срок действия, зависящий от политики, и сделайте запись недействительной после успешного использования. Когда пользователь нажимает ссылку, найдите пользователя по электронной почте, получите сохраненный хэш, сравните предоставленный токен с хэшем, проверьте срок действия и выполните сброс, только если токен действителен и срок его действия еще не истек. Немедленно аннулируйте токен (удалите его или пометьте как использованный), чтобы его нельзя было использовать повторно. Никогда не регистрируйте необработанный токен; регистрируйте только идентификатор пользователя и действие.
Обработка токена на стороне сервера: храните хэш, устанавливайте срок действия, признавайте недействительным при использовании и никогда не записывайте необработанное значение.
Токен никогда не должен появляться в сообщениях об ошибках или в базе данных, если он не хеширован. Разработка полной аутентификации выходит за рамки статьи UUID, но принципы сохраняются: случайный 122-битный токен по своей сути не является токеном доступа. Случайность — это самая простая часть; генератор ToolAcre предоставляет вам UUID на основе CSPRNG. Самая сложная часть — это дизайн: хеширование перед сохранением, установка времени истечения срока действия, аннулирование при использовании, предотвращение повторного использования постоянных идентификаторов в качестве временных секретов, проверка того, кто, к чему и когда обращался. Эксперт по безопасности, одобряющий схему сброса ссылок, основанную только на энтропии токена, пропускает остальную часть анализа. Разработчик, который считает, что UUID с поддержкой CSPRNG достаточно для ссылки для сброса пароля без хеширования, истечения срока действия и аннулирования, недооценивает угрозу. Случайность защищает от догадок; дизайн защищает от повторного воспроизведения, истечения срока действия и неправильного использования.
Рабочий пример — проверка схемы сброса ссылок для каждой проверки и переписывание слабых частей.
Генератор ToolAcre правильно выполняет часть случайности; приложение должно правильно выполнить проектную часть. Проверьте свой собственный код ссылки сброса на соответствие всем трем проверкам: использует ли он CSPRNG (crypto.getRandomValues, crypto.randomUUID или библиотеку шифрования), а не Math.random? Имеет ли токен срок действия? Хешируется ли токен перед сохранением? Становится ли токен недействительным после использования? Избегает ли код повторного использования постоянного идентификатора пользователя в качестве временного токена? Если вы ответите «да» на все эти вопросы, ваша ссылка для сброса работает правильно. Генератор ToolAcre является частью CSPRNG; остальное — это код приложения, который необходимо внимательно просмотреть. Понимание трех уровней безопасности поможет вам проводить аудит сторонних UUID библиотек и платформ. Когда вы оцениваете библиотеку, убедитесь, что она использует CSPRNG (проверка энтропии), а не слабый случайный источник. Убедитесь, что он документирует, какие источники он использует и почему (проверка генератора).
Что здесь не распространяется — полная аутентификация, MFA и ограничение скорости, которые имеют такое же значение, как и энтропия токена.
Убедитесь, что пример кода и документация подчеркивают принципы проектирования: хеширование, срок действия, аннулирование (проверка дизайна). Библиотеки, прошедшие все три проверки, встречаются редко; большинство сосредотачивается только на энтропии. Генератор ToolAcre проходит проверку энтропии и генератора с помощью crypto.getRandomValues. Проверка проекта — ваша ответственность; библиотека не может знать ваши требования к сроку действия или стратегию хеширования. Отладка сломанной системы сброса ссылок обычно выявляет одну из трех ошибок. Если пользователи сообщают о получении ссылок сброса, которые больше не работают, вероятная проблема заключается в истечении срока действия: токен был выпущен, но срок его действия истек до того, как пользователь щелкнул ссылку. Если токены используются повторно несколько раз, аннулирование нарушается. Если токены появляются в сообщениях об ошибках или выходных данных отладки, это значит, что в журнале происходит их утечка. Если ссылки сброса работают для одного пользователя, но не для другого, могут возникнуть проблемы с задержкой репликации базы данных или часовым поясом при расчете срока действия. Если законные запросы на сброс случайно завершаются неудачей, CSPRNG может быть сломан (редко).
Вывод: случайность — это самая простая часть: генератор ToolAcre дает вам UUID, поддерживаемый CSPRNG; остальное - дизайнерская дисциплина
Начните с ведения журнала: включите подробные журналы аудита для создания и проверки ссылок сброса, затем воспроизведите проблему и проследите поток. Генератор ToolAcre обеспечивает прохождение первых двух проверок; Устранение неполадок, связанных со сбросом ссылки, почти всегда относится к категории проектирования. Лучшие практики для производственных систем сброса ссылок включают в себя: генерировать новый случайный токен для каждого запроса на сброс, а не повторно использовать старые токены. Сохраните одностороннее представление вместе с метаданными учетной записи и создания, а затем выберите срок действия из документированной политики риска службы. Аннулируйте токен сразу после успешной проверки. Регистрируйте запросы на сброс и успешные результаты для аудита. Внедрите ограничение скорости для предотвращения атак методом перебора. Отправляйте ссылки для сброса только по электронной почте, а не по SMS или по незашифрованным каналам. Уведомляйте пользователя о попытках сброса пароля (чтобы он мог обнаружить несанкционированный сброс). Генератор ToolAcre дает вам случайность; следование этим правилам дает вам безопасность.