Неофициальный русский перевод

SP 800-63B-4
3.1.1 Пароли

Фрагмент прошёл независимую смысловую проверку

Полностью переведён только раздел 3.1.1, включая 3.1.1.1 и 3.1.1.2. Полный перевод документа продолжается. Официальный оригинал · копия от 3 октября 2026 года.

Пароль (иногда называемый парольной фразой (passphrase) или, если он числовой, персональным идентификационным номером [PIN]) — это секретное значение, которое предполагается, что абонент выберет, а затем либо запомнит, либо запишет. Пароли должны обладать достаточной фактической стойкостью и секретностью, чтобы для атакующего было непрактично угадать или иным образом обнаружить правильное секретное значение. Пароль — это «то, что вы знаете».

Требования этого раздела применяются к централизованно проверяемым паролям, которые используются как независимые факторы аутентификации и передаются средству проверки по аутентифицированному защищённому каналу. Пароли, используемые локально как фактор активации многофакторного аутентификатора (например, PIN для разблокировки), называются секретами активации (activation secrets) и рассматриваются в разд. 3.2.10. В отличие от централизованно проверяемых паролей, секреты активации (подобно паролям разблокировки или PIN на многих устройствах) не передаются средству проверки; вместо этого они используются локально для получения доступа к секрету аутентификации.

Пароли не устойчивы к фишингу.

3.1.1.1 Аутентификаторы-пароли

Пароли ДОЛЖНЫ (SHALL) либо выбираться абонентом, либо случайно назначаться CSP.

Если CSP запрещает выбранный пароль, потому что тот находится в блок-листе часто используемых, ожидаемых или скомпрометированных значений (см. разд. 3.1.1.2), абонент ДОЛЖЕН (SHALL) выбрать другой пароль. Другие требования к составу пароля НЕ ДОЛЖНЫ (SHALL NOT) устанавливаться. Обоснование приведено в приложении A, Strength of Passwords.

3.1.1.2 Средства проверки паролей

К паролям применяются следующие требования:

1. Средства проверки и CSP ДОЛЖНЫ (SHALL) требовать, чтобы длина паролей, используемых как однофакторный механизм аутентификации, составляла не менее 15 символов. Средства проверки и CSP МОГУТ (MAY) разрешать пароли, используемые только как часть процессов многофакторной аутентификации, меньшей длины, но ДОЛЖНЫ (SHALL) требовать для них длину не менее восьми символов.
2. Средствам проверки и CSP СЛЕДУЕТ (SHOULD) разрешать максимальную длину пароля не менее 64 символов.
3. Средствам проверки и CSP СЛЕДУЕТ (SHOULD) принимать в паролях все печатаемые символы ASCII из RFC20 и символ пробела.
4. Средствам проверки и CSP СЛЕДУЕТ (SHOULD) принимать в паролях символы Unicode ISO/ISC 10646. При оценке длины пароля каждая кодовая точка Unicode ДОЛЖНА (SHALL) учитываться как один символ.
5. Средства проверки и CSP НЕ ДОЛЖНЫ (SHALL NOT) устанавливать для паролей другие правила состава, например требовать сочетания различных типов символов.
6. Средства проверки и CSP НЕ ДОЛЖНЫ (SHALL NOT) требовать от абонентов периодически менять пароли. Однако при наличии свидетельств компрометации аутентификатора средства проверки ДОЛЖНЫ (SHALL) принудительно требовать смену.
7. Средства проверки и CSP НЕ ДОЛЖНЫ (SHALL NOT) разрешать абоненту хранить подсказку, например напоминание о способе создания пароля, доступную неаутентифицированному заявителю.
8. Средства проверки и CSP НЕ ДОЛЖНЫ (SHALL NOT) предлагать абонентам использовать аутентификацию на основе знаний (KBA), например вопрос «Как звали вашего первого питомца?», или контрольные вопросы при выборе паролей.
9. Средства проверки ДОЛЖНЫ (SHALL) запрашивать пароль полностью, а не только его часть, и ДОЛЖНЫ (SHALL) проверять весь представленный пароль, например не усекать его.

Если в паролях принимаются символы Unicode, средству проверки СЛЕДУЕТ (SHOULD) применять процесс нормализации стабилизированных строк с использованием нормализации Normalization Form Canonical Composition (NFC), определённой в разд. 12.1 Unicode Normalization Forms UAX15. Этот процесс применяется до хеширования строки байтов, представляющей пароль. Абонентам, выбирающим пароли с символами Unicode, СЛЕДУЕТ (SHOULD) сообщать, что некоторые конечные точки могут представлять некоторые символы по-разному, что повлияет на возможность успешно пройти аутентификацию.

При обработке запроса на установку или смену пароля средства проверки ДОЛЖНЫ (SHALL) сравнивать предполагаемый секрет с блок-листом, содержащим известные часто используемые, ожидаемые или скомпрометированные пароли. Сравнению ДОЛЖЕН (SHALL) подвергаться весь пароль, а не его подстроки или слова, которые он может содержать. Например, список может включать:

• Пароли, полученные из массивов данных предыдущих утечек.
• Словарные слова.
• Контекстно-зависимые слова, такие как имя сервиса, имя пользователя и их производные.

Если выбранный пароль найден в блок-листе, CSP ДОЛЖЕН (SHALL) потребовать от абонента выбрать другой секрет и ДОЛЖЕН (SHALL) указать причину отклонения. Поскольку блок-лист используется для защиты от атак перебором, а неуспешные попытки ограничиваются по частоте, размер блок-листа СЛЕДУЕТ (SHOULD) выбирать достаточным, чтобы не дать абонентам выбирать пароли, которые атакующие, вероятно, угадают до достижения лимита попыток.

Чрезмерно большие блок-листы дают лишь небольшую дополнительную выгоду для безопасности, потому что блок-лист применяется для защиты от сетевых атак, которые уже ограничены требованиями по ограничению частоты, описанными в разд. 3.2.2.

Средства проверки ДОЛЖНЫ (SHALL) предоставлять абоненту рекомендации, помогающие выбрать стойкий пароль. Это особенно важно после отклонения пароля по блок-листу, поскольку препятствует тривиальному изменению включённых в список слабых паролей Blocklists.

Средства проверки ДОЛЖНЫ (SHALL) реализовать механизм ограничения частоты, который эффективно ограничивает число неуспешных попыток аутентификации, возможных для учётной записи абонента, как описано в разд. 3.2.2.

Средства проверки ДОЛЖНЫ (SHALL) разрешать использование менеджеров паролей и функций автозаполнения. Средствам проверки СЛЕДУЕТ (SHOULD) разрешать заявителям использовать функцию «вставить» при вводе пароля, чтобы облегчить использование менеджеров паролей, когда API автозаполнения паролей недоступны. Показано, что менеджеры паролей повышают вероятность того, что абоненты выберут более стойкие пароли, особенно если менеджеры паролей включают генераторы паролей Managers.

Чтобы помочь заявителю успешно ввести пароль, средству проверки СЛЕДУЕТ (SHOULD) предоставлять возможность отображать пароль, а не ряд точек или звёздочек, во время его ввода и до его передачи средству проверки. Это позволяет заявителю подтвердить ввод, если он находится в месте, где маловероятно наблюдение за его экраном. Средство проверки МОЖЕТ (MAY) также разрешать устройству заявителя кратковременно отображать отдельные введённые символы после ввода каждого символа для проверки правильности ввода. Это распространено на мобильных устройствах.

Средства проверки МОГУТ (MAY) допускать ограниченные послабления при опечатках, например удалять начальные и конечные пробельные символы до проверки или разрешать проверку паролей с отличающимся регистром первого символа, если после такой обработки пароль остаётся не короче требуемой минимальной длины и сложность полученного пароля существенно не снижается.

Средства проверки и CSP ДОЛЖНЫ (SHALL) применять утверждённое шифрование и аутентифицированный защищённый канал при запросе паролей.

Средства проверки ДОЛЖНЫ (SHALL) хранить пароли в форме, устойчивой к офлайн-атакам. Пароли ДОЛЖНЫ (SHALL) быть снабжены солью (salted) и хешированы с использованием подходящей схемы хеширования паролей. Схемы хеширования паролей принимают пароль, соль и коэффициент стоимости в качестве входных данных и создают хеш пароля. Их назначение — сделать каждую попытку угадывания пароля более затратной для атакующего, получившего файл хешированных паролей, тем самым делая стоимость атаки угадывания высокой или неприемлемой. Выбранный коэффициент стоимости СЛЕДУЕТ (SHOULD) устанавливать настолько высоким, насколько это практически возможно без отрицательного влияния на производительность средства проверки. Его СЛЕДУЕТ (SHOULD) увеличивать со временем с учётом роста производительности вычислений. СЛЕДУЕТ (SHOULD) использовать утверждённую схему хеширования паролей, опубликованную в последней редакции SP800-132, или обновлённые руководства NIST по схемам хеширования паролей. Длину выбранного вывода верификатора пароля, исключая соль и сведения о версии, СЛЕДУЕТ (SHOULD) устанавливать равной длине вывода базовой схемы хеширования паролей.

Длина соли ДОЛЖНА (SHALL) составлять не менее 32 бит, а сама соль должна быть выбрана так, чтобы минимизировать коллизии значений соли среди хранимых хешей, то есть не допустить наличия одного и того же хешированного пароля у нескольких учётных записей абонентов. Для каждого пароля ДОЛЖНЫ (SHALL) храниться и значение соли, и результирующий хеш. Для каждого пароля СЛЕДУЕТ (SHOULD) хранить ссылку на использованную схему хеширования паролей, включая коэффициент стоимости, чтобы обеспечить миграцию на новые алгоритмы и факторы работы.

Кроме того, средствам проверки СЛЕДУЕТ (SHOULD) выполнять дополнительную итерацию операции хеширования с ключом или шифрования с использованием секретного ключа, известного только средству проверки. Если этот ключ используется, его значение ДОЛЖНО (SHALL) генерироваться утверждённым генератором случайных битов, как описано в разд. 3.2.12. Значение секретного ключа ДОЛЖНО (SHALL) храниться отдельно от хешированных паролей. Его СЛЕДУЕТ (SHOULD) хранить и использовать в аппаратно защищённой области, например в аппаратном модуле безопасности или доверенной среде исполнения (TEE), такой как доверенный платформенный модуль (TPM). При такой дополнительной итерации атаки перебором на хешированные пароли непрактичны, пока значение секретного ключа остаётся секретным.

Примечания переводчика

• CSP — credential service provider, поставщик услуг управления учётными данными. Расшифровка подтверждается введением оригинала; английская аббревиатура сохранена.
• Verifier — средство проверки, claimant — заявитель, subscriber — абонент. В предложении о длине вывода «верификатор пароля» означает результат схемы хеширования, а не проверяющую систему.
• «Утверждённый» передаёт approved без самостоятельного расширения сферы применимости.
• Обозначение ISO/ISC 10646 воспроизводит исходный текст. Возможная опечатка оригинала не исправляется переводом. Нумерация Passwords 3.1.1 подтверждается внутренними ссылками оригинала; его подразделы — 3.1.1.1 и 3.1.1.2.
• SHALL/SHALL NOT — обязательное требование/запрет; SHOULD/SHOULD NOT — рекомендация/нежелательность; MAY — разрешение. Английские модальные термины сохранены для проверки силы формулировок.