⌕ Поиск по атласу

Неофициальный полный русский перевод · SP 800-63B-4

SP 800-63B-4 · Руководство по цифровой идентификации: аутентификация и управление аутентификаторами

Digital Identity Guidelines: Authentication and Authenticator Management

Карточка документа · Архив принятого перевода · Официальный источник

Содержание

Проверить наличие обновлений.

Специальная публикация NIST

NIST SP 800-63B-4

Руководство по цифровой идентичности

Аутентификация и управление аутентификаторами

David Temoshok
James L. Fenton
Yee-Yin Choong
Naomi Lefkovitz
Andrew Regenscheid
Ryan Galluzzo
Justin P. Richer

Эта публикация доступна бесплатно по адресу:
https://doi.org/10.6028/NIST.SP.800-63B-4

Специальная публикация NIST

NIST SP 800-63B-4

Руководство по цифровой идентичности

Аутентификация и управление аутентификаторами

David Temoshok
Naomi Lefkovitz *
Ryan Galluzzo

Подразделение прикладной кибербезопасности
Лаборатория информационных технологий

Yee-Yin Choong

Подразделение доступа к информации
Лаборатория информационных технологий

Andrew Regenscheid

Подразделение компьютерной безопасности
Лаборатория информационных технологий

James L. Fenton

Altmode Networks

Justin P. Richer

Bespoke Engineering

* Бывший сотрудник NIST; вся работа над этой публикацией была выполнена во время работы в NIST.

Эта публикация доступна бесплатно по адресу:
https://doi.org/10.6028/NIST.SP.800-63B-4

Июль 2025 г.

Министерство торговли США
Howard Lutnick, министр

Национальный институт стандартов и технологий
Craig Burkhardt, исполняющий обязанности заместителя министра по стандартам и технологиям и исполняющий обязанности директора NIST

Некоторое оборудование, приборы, программное обеспечение или материалы, коммерческие или некоммерческие, указаны в этой работе для надлежащего описания экспериментальной процедуры. Такое указание не подразумевает рекомендации или одобрения какого-либо продукта или услуги со стороны NIST, равно как не подразумевает, что указанные материалы или оборудование обязательно являются наилучшими доступными для этой цели.

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

Организациям рекомендуется ознакомиться со всеми проектами публикаций в периоды общественного обсуждения и направить NIST свои отзывы. Многие публикации NIST по кибербезопасности, помимо отмеченных выше, доступны по адресу https://csrc.nist.gov/publications.

Полномочия

Эта публикация была разработана NIST в соответствии с его предусмотренными законом обязанностями по Федеральному закону о модернизации информационной безопасности (FISMA) 2014 года, 44 U.S.C. § 3551 и последующие положения, Public Law (P.L.) 113-283. NIST отвечает за разработку стандартов и руководств по информационной безопасности, включая минимальные требования для федеральных информационных систем, однако такие стандарты и руководства не применяются к системам национальной безопасности без прямого одобрения соответствующих федеральных должностных лиц, осуществляющих полномочия по выработке политики в отношении таких систем. Настоящее руководство соответствует требованиям циркуляра A-130 Управления по вопросам управления и бюджета (OMB).

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

Политики технических серий NIST

Заявления об авторском праве, добросовестном использовании и лицензировании
Синтаксис идентификатора публикации технической серии NIST

История публикации

Одобрена Редакционной коллегией NIST 2025-05-30.
Заменяет NIST SP 800-63B (июнь 2017 г.; обновлено 2 марта 2020 г.) https://doi.org/10.6028/NIST.SP.800-63b

Как цитировать эту публикацию технической серии NIST

Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Galluzzo R, Richer JP (2025) Digital Identity Guidelines: Authentication and Authenticator Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63B-4. https://doi.org/10.6028/NIST.SP.800-63B-4

ORCID iDs авторов

David Temoshok: 0000-0001-6195-0331
James L. Fenton: 0000-0002-2344-4291
Yee-Yin Choong: 0000-0002-3889-6047
Naomi Lefkovitz: 0000-0003-3777-3106
Andrew Regenscheid: 0000-0002-3930-527X
Ryan Galluzzo: 0000-0003-0304-4239
Justin P. Richer: 0000-0003-2130-5180

Контактная информация

mailto:dig-comments@nist.gov

Национальный институт стандартов и технологий
Вниманию: Подразделение прикладной кибербезопасности, Лаборатория информационных технологий
100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000

Дополнительная информация

Дополнительная информация об этой публикации доступна по адресу https://csrc.nist.gov/pubs/sp/800/63/B/4/final, включая связанное содержимое, возможные обновления и историю документа.

Все комментарии подлежат раскрытию в соответствии с Законом о свободе информации (FOIA).

NIST SP 800-63B-4 — Руководство по цифровой идентичности
Июль 2025 г. — Аутентификация и управление аутентификаторами

Аннотация

Настоящее руководство посвящено аутентификации субъектов, которые взаимодействуют с государственными информационными системами через сети, чтобы установить, что данный заявитель является подписчиком, ранее прошедшим аутентификацию. Результат процесса аутентификации может использоваться локально системой, выполняющей аутентификацию, либо утверждаться в другом месте федеративной системы идентификации. Этот документ определяет технические требования для каждого из трёх уровней доверия аутентификации. Руководства не предназначены для ограничения разработки или использования стандартов вне этой цели. Эта публикация заменяет специальную публикацию NIST (SP) 800-63B.

Ключевые слова

аутентификация; доверие к аутентификации; поставщик услуг учётных данных; цифровая аутентификация; пароли.

Отчёты по технологии компьютерных систем

Лаборатория информационных технологий (ITL) Национального института стандартов и технологий (NIST) содействует экономике и общественному благосостоянию США, обеспечивая техническое лидерство в области национальной инфраструктуры измерений и стандартов. ITL разрабатывает испытания, методы испытаний, эталонные данные, реализации для подтверждения концепции и технические анализы, чтобы содействовать развитию и продуктивному использованию информационных технологий. В обязанности ITL входит разработка управленческих, административных, технических и физических стандартов и руководств для экономически эффективной безопасности и конфиденциальности информации в федеральных информационных системах, не относящейся к национальной безопасности. Отчёты серии специальной публикации 800 освещают исследования ITL, руководства и деятельность по взаимодействию в области безопасности информационных систем, а также его совместную деятельность с промышленностью, государственными и академическими организациями.

i

NIST SP 800-63B-4 — Руководство по цифровой идентичности
Июль 2025 г. — Аутентификация и управление аутентификаторами

Уведомление о раскрытии патентов

УВЕДОМЛЕНИЕ: ITL обратилось к держателям патентных притязаний, использование которых может потребоваться для соблюдения руководства или требований этой публикации, с просьбой раскрыть такие патентные притязания ITL. Однако держатели патентов не обязаны отвечать на запросы ITL о патентах, и ITL не проводила патентный поиск, чтобы определить, какие патенты, если таковые имеются, могут относиться к этой публикации.

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

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

ii

NIST SP 800-63B-4: Руководство по цифровой идентификации

Июль 2025

Аутентификация и управление аутентификаторами

Содержание

  1. 1. Введение — 1
    1. 1.1. Обозначения — 2
    2. 1.2. Структура документа — 3
  2. 2. Уровни доверия аутентификации — 4
    1. 2.1. Уровень доверия аутентификации 1 — 4
      1. 2.1.1. Допустимые типы аутентификаторов — 5
      2. 2.1.2. Требования к аутентификаторам и верификаторам — 5
      3. 2.1.3. Повторная аутентификация — 5
    2. 2.2. Уровень доверия аутентификации 2 — 6
      1. 2.2.1. Допустимые типы аутентификаторов — 6
      2. 2.2.2. Требования к аутентификаторам и верификаторам — 7
      3. 2.2.3. Повторная аутентификация — 7
    3. 2.3. Уровень доверия аутентификации 3 — 8
      1. 2.3.1. Допустимые типы аутентификаторов — 8
      2. 2.3.2. Требования к аутентификаторам и верификаторам — 8
      3. 2.3.3. Повторная аутентификация — 9
    4. 2.4. Общие требования — 9
      1. 2.4.1. Меры контроля безопасности — 9
      2. 2.4.2. Политика хранения записей — 9
      3. 2.4.3. Требования к конфиденциальности — 9
      4. 2.4.4. Требования к восстановлению прав — 10
    5. 2.5. Сводка требований — 11
  3. 3. Требования к аутентификаторам и верификаторам — 12
    1. 3.1. Требования по типу аутентификатора — 13
      1. 3.1.1. Пароли — 13
      2. 3.1.2. Секреты для поиска — 17
      3. 3.1.3. Внеполосные устройства — 18
      4. 3.1.4. Однофакторный одноразовый пароль (OTP) — 23
      5. 3.1.5. Многофакторные OTP — 25

iii

  1. 3.1.6. Однофакторная криптографическая аутентификация — 26
  2. 3.1.7. Многофакторная криптографическая аутентификация — 27
  3. 3.2. Общие требования к аутентификаторам — 30
    1. 3.2.1. Физические аутентификаторы — 30
    2. 3.2.2. Ограничение частоты (дросселирование) — 30
    3. 3.2.3. Использование биометрии — 31
    4. 3.2.4. Аттестация — 34
    5. 3.2.5. Устойчивость к фишингу — 35
    6. 3.2.6. Связь между верификатором и CSP или IdP — 36
    7. 3.2.7. Устойчивость к повторному воспроизведению — 36
    8. 3.2.8. Намерение аутентификации — 37
    9. 3.2.9. Ограниченные аутентификаторы — 37
    10. 3.2.10. Секреты активации — 38
    11. 3.2.11. Подключённые аутентификаторы — 39
    12. 3.2.12. Случайные значения — 41
    13. 3.2.13. Экспортируемость — 41
  4. 4. Управление событиями аутентификатора — 43
    1. 4.1. Привязка аутентификатора — 43
      1. 4.1.1. Привязка при регистрации — 44
      2. 4.1.2. Привязка после регистрации — 44
      3. 4.1.3. Привязка к аутентификатору, предоставленному подписчиком — 46
      4. 4.1.4. Продление — 46
    2. 4.2. Восстановление учётной записи — 47
      1. 4.2.1. Методы восстановления учётной записи — 47
      2. 4.2.2. Требования к восстановлению по IAL/AAL — 49
      3. 4.2.3. Уведомление о восстановлении учётной записи — 50
    3. 4.3. Утрата, кража, повреждение и компрометация — 50
    4. 4.4. Истечение срока действия — 51
    5. 4.5. Аннулирование — 51
    6. 4.6. Уведомления об учётной записи — 51

iv

  1. 5. Управление сеансами — 53
    1. 5.1. Привязки сеанса — 53
      1. 5.1.1. Файлы cookie браузера — 55
      2. 5.1.2. Токены доступа — 55
    2. 5.2. Повторная аутентификация — 56
    3. 5.3. Мониторинг сеанса — 57
  2. 6. Угрозы и вопросы безопасности — 58
    1. 6.1. Угрозы аутентификаторов — 58
    2. 6.2. Стратегии смягчения угроз — 62
    3. 6.3. Восстановление аутентификатора — 65
    4. 6.4. Атаки на сеансы — 65
  3. 7. Вопросы конфиденциальности — 66
    1. 7.1. Оценка риска для конфиденциальности — 66
    2. 7.2. Меры контроля конфиденциальности — 66
    3. 7.3. Ограничение использования — 66
    4. 7.4. Соблюдение требований конфиденциальности, специфичных для агентства — 67
  4. 8. Вопросы пользовательского опыта — 68
    1. 8.1. Удобство использования — 68
      1. 8.1.1. Общие соображения по удобству использования аутентификаторов — 69
      2. 8.1.2. Соображения по удобству использования в зависимости от типа аутентификатора — 71
      3. 8.1.3. Сводка соображений по удобству использования — 76
      4. 8.1.4. Соображения по удобству использования биометрии — 76
    2. 8.2. Соображения по успеху клиентов — 79

Ссылки — 81

Приложение A. Стойкость паролей — 87

  1. A.1. Введение — 87
  2. A.2. Длина — 87
  3. A.3. Сложность — 88
  4. A.4. Централизованная и локальная проверка — 89
  5. A.5. Сводка — 90

v

Приложение B. Синхронизируемые аутентификаторы — 91

  1. B.1. Введение — 91
  2. B.2. Клонирование ключей аутентификации — 91
  3. B.3. Требования к реализации — 92
  4. B.4. Совместное использование — 94
  5. B.5. Пример — 95
  6. B.6. Вопросы безопасности — 96

Приложение C. Перечень символов, сокращений и акронимов — 99

Приложение D. Глоссарий — 102

Приложение E. Журнал изменений — 117

Список таблиц

  1. Таблица 1. Сводка требований по AAL — 11
  2. Таблица 2. Сводка секретов (ненормативная) — 12
  3. Таблица 3. Угрозы аутентификаторов — 58
  4. Таблица 4. Смягчение угроз аутентификаторов — 62
  5. Таблица 5. Угрозы, проблемы и меры смягчения для синхронизируемых аутентификаторов — 96

Список рисунков

  1. Рис. 1. Передача секрета на основное устройство — 19
  2. Рис. 2. Передача секрета на внеполосное устройство — 19
  3. Рис. 3. Соображения по удобству использования в зависимости от типа аутентификатора — 77

vi

Предисловие

Данная публикация и сопутствующие ей тома — [SP800-63], [SP800-63A] и [SP800-63C] — содержат технические руководящие указания для организаций по внедрению служб цифровой идентификации.

Настоящий документ, SP 800-63B, устанавливает требования к поставщикам услуг учётных данных (CSP) для удалённой аутентификации пользователей на каждом из трёх уровней доверия аутентификации (AAL).

Благодарности

Авторы хотели бы поблагодарить своих коллег-сотрудников — Christine Abruzzi, Sarbari Gupta, Connie LaSalle, Diana Proud-Madruga и Maria Vachino — за работу над текущей редакцией этой специальной публикации, а также Kerrianne Buchanan, Greg Fiumara и Evelyn Petrella за их вклад и рецензирование. Авторы также хотели бы отметить прошлый вклад Donna F. Dodson, W. Timothy Polk, Emad A. Nabbus, Paul A. Grassi, Elaine M. Newton, Ray Perlner, William E. Burr, Kristen K. Greene, Mary F. Theofanos, Kaitlin Boeckl, Kat Megas, Ellen Nadeau, Ben Piccarreta и Danna Gabel O’Rourke.

vii

NIST SP 800-63B-4
Июль 2025

Digital Identity Guidelines: Authentication and Authenticator Management

1. Введение

Этот раздел носит информационный характер.

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

Аутентификация заявителей является центральной частью процесса связывания подписчика с его деятельностью в Интернете, зафиксированной в его учетной записи подписчика, которую ведет поставщик услуг учетных данных (CSP). Аутентификация выполняется путем проверки того, что заявитель контролирует один или несколько аутентификаторов (в некоторых более ранних редакциях SP 800-63 называвшихся токенами), связанных с данной учетной записью подписчика. Процесс аутентификации осуществляет верификатор, являющийся ролью CSP или — при федеративной аутентификации — поставщика удостоверений (IdP). При успешной аутентификации верификатор передает идентификатор подписчика полагающейся стороне (RP). Необязательно верификатор также может передавать RP дополнительные атрибуты.

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

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

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

AAL классифицируют надежность транзакции аутентификации. Более сильная аутентификация (то есть более высокий AAL) требует от злоумышленников более высоких возможностей и расходования больших ресурсов для успешного подрыва процесса аутентификации. Аутентификация на более высоких AAL может эффективно снизить риск атак. Ниже приведено обобщенное описание технических требований для каждого AAL; конкретные нормативные требования приведены в разд. 2 и разд. 3 настоящего документа.

1

NIST SP 800-63B-4
Июль 2025

Digital Identity Guidelines: Authentication and Authenticator Management

Уровень доверия аутентификации 1: AAL1 обеспечивает базовую уверенность в том, что заявитель контролирует аутентификатор, связанный с аутентифицируемой учетной записью подписчика. AAL1 требует только однофакторной аутентификации с использованием широкого спектра доступных технологий аутентификации. Однако рекомендуется, чтобы приложения, оцениваемые на AAL1, предлагали варианты многофакторной аутентификации. Успешная аутентификация требует, чтобы заявитель доказал владение аутентификатором и контроль над ним.

Уровень доверия аутентификации 2: AAL2 обеспечивает высокую уверенность в том, что заявитель контролирует один или несколько аутентификаторов, связанных с аутентифицируемой учетной записью подписчика. Требуется доказательство владения и контроля над двумя различными факторами аутентификации. Приложения, оцениваемые на AAL2, должны предлагать вариант аутентификации, устойчивой к фишингу (см. разд. 3.2.5).

Уровень доверия аутентификации 3: AAL3 обеспечивает очень высокую уверенность в том, что заявитель контролирует один или несколько аутентификаторов, связанных с аутентифицируемой учетной записью подписчика. Аутентификация на AAL3 основана на доказательстве владения ключом посредством использования криптографического протокола с открытым ключом. Аутентификация AAL3 требует устойчивого к фишингу аутентификатора (см. разд. 3.2.5) с неэкспортируемым ключом аутентификации (см. разд. 3.2.13). Для аутентификации на AAL3 заявители должны доказать владение и контроль над двумя различными факторами аутентификации.

Когда сеанс был аутентифицирован на данном AAL и требуется более высокий AAL, процесс аутентификации также может предоставлять пошаговую аутентификацию для повышения AAL сеанса.

1.1. Обозначения

В настоящем руководстве в тексте используются следующие типографические соглашения:

  • Конкретные термины, написанные ПРОПИСНЫМИ БУКВАМИ, представляют нормативные требования. Если те же термины написаны не ПРОПИСНЫМИ БУКВАМИ, термин не представляет нормативное требование.
    • Термины «ДОЛЖЕН (SHALL)» и «НЕ ДОЛЖЕН (SHALL NOT)» указывают на требования, которые необходимо строго соблюдать для соответствия публикации и от которых не допускается никаких отступлений.
    • Термины «СЛЕДУЕТ (SHOULD)» и «НЕ СЛЕДУЕТ (SHOULD NOT)» указывают, что среди нескольких возможностей одна рекомендуется как особенно подходящая без упоминания или исключения других, что определенный образ действий является предпочтительным, но не обязательно требуемым, или что (в отрицательной форме) определенная возможность или образ действий не поощряется, но не запрещается.
    • Термины «МОЖЕТ (MAY)» и «НЕ ОБЯЗАН (NEED NOT)» указывают на образ действий, допустимый в пределах настоящей публикации.
    • Термины «МОЖЕТ (CAN)» и «НЕ МОЖЕТ (CANNOT)» указывают на возможность и способность — материальную, физическую или причинную — либо, в отрицательной форме, на отсутствие такой возможности или способности.

2

NIST SP 800-63B-4
Июль 2025

Digital Identity Guidelines: Authentication and Authenticator Management

1.2. Структура документа

Настоящий документ организован следующим образом. Каждый раздел обозначен как нормативный (то есть обязательный для соответствия) либо информационный (то есть необязательный).

  • Раздел 1 знакомит с документом. Этот раздел носит информационный характер.
  • Раздел 2 описывает требования к AAL. Этот раздел является нормативным.
  • Раздел 3 описывает требования к аутентификаторам и верификаторам. Этот раздел является нормативным.
  • Раздел 4 описывает требования к управлению событиями аутентификаторов. Этот раздел является нормативным.
  • Раздел 5 описывает требования к управлению сеансами. Этот раздел является нормативным.
  • Раздел 6 содержит соображения безопасности. Этот раздел носит информационный характер.
  • Раздел 7 содержит соображения конфиденциальности. Этот раздел носит информационный характер.
  • Раздел 8 содержит соображения пользовательского опыта. Этот раздел носит информационный характер.
  • Раздел «Ссылки» содержит перечень публикаций, на которые ссылается настоящий документ. Этот раздел носит информационный характер.
  • Приложение A рассматривает надежность паролей. Это приложение носит информационный характер.
  • Приложение B рассматривает синхронизируемые аутентификаторы. Это приложение является нормативным.
  • Приложение C содержит избранный перечень сокращений, используемых в настоящем документе. Это приложение носит информационный характер.
  • Приложение D содержит глоссарий избранных терминов, используемых в настоящем документе. Это приложение носит информационный характер.
  • Приложение E содержит сводный перечень изменений в истории настоящего документа. Это приложение носит информационный характер.

3

NIST SP 800-63B-4
Июль 2025

Digital Identity Guidelines: Authentication and Authenticator Management

2. Уровни доверия аутентификации

Этот раздел является нормативным.

Чтобы удовлетворить требованиям данного AAL и быть признанным подписчиком, заявитель ДОЛЖЕН (SHALL) проходить аутентификацию перед RP (или IdP, как описано в [SP800-63C]) с процессом, надежность которого равна требованиям этого уровня или превышает их. Процесс аутентификации приводит к идентификатору, который однозначно идентифицирует подписчика при каждой его аутентификации перед этой RP. Идентификатор МОЖЕТ (MAY) быть псевдонимным. Также МОГУТ (MAY) предоставляться другие атрибуты, идентифицирующие подписчика как уникальный субъект. Подробные нормативные требования к аутентификаторам и верификаторам на каждом AAL приведены в разд. 3. Подробные сведения о выборе наиболее подходящего AAL см. в разд. 3 документа [SP800-63].

Персональная информация, собранная в ходе и после установления личности (см. [SP800-63A]), МОЖЕТ (MAY) предоставляться подписчику службой цифровой идентификации через учетную запись подписчика. Раскрытие или доступность в Интернете любой персональной информации федеральными агентствами требует многофакторной аутентификации в соответствии с [EO13681]. Поэтому федеральные агентства ДОЛЖНЫ (SHALL) выбирать как минимум AAL2, когда персональная информация становится доступной в Интернете.

На всех AAL индикаторы потенциального мошенничества, включая применимые индикаторы, описанные в разд. 5.3, МОГУТ (MAY) использоваться для снижения риска ошибочной аутентификации. Например, аутентификация из неожиданной геолокации или блока IP-адресов (например, облачной службы) может побудить к использованию дополнительных мер контроля, основанных на риске. CSP или верификаторы ДОЛЖНЫ (SHALL) оценивать эффективность использования ими индикаторов потенциального мошенничества, а также выявлять и смягчать возможные негативные последствия для своих пользовательских групп. CSP или верификаторы ДОЛЖНЫ (SHALL) включать индикаторы мошенничества в оценку рисков для конфиденциальности при аутентификации. Использование индикаторов потенциального мошенничества до или во время процесса аутентификации не влияет на AAL транзакции, не изменяет его и не заменяет фактор аутентификации.

Во всем настоящем документе требования [FIPS140] удовлетворяются технологиями, продуктами и службами безопасности, использующими реализации криптографии, валидированные Программой валидации криптографических модулей [CMVP]. Требования FIPS 140 на данном AAL часто различаются для аутентификаторов и верификаторов; более строгие требования обычно применяются к верификаторам. Это признает практические ограничения сертификации аутентификаторов, а также более широкий масштаб последствий, часто связанных с нарушением безопасности у верификатора.

2.1. Уровень доверия аутентификации 1

AAL1 обеспечивает базовую уверенность в том, что заявитель контролирует аутентификатор, связанный с учетной записью подписчика. AAL1 требует однофакторной либо многофакторной аутентификации с использованием широкого спектра доступных технологий аутентификации. Верификаторам СЛЕДУЕТ (SHOULD) предоставлять на AAL1 варианты многофакторной аутентификации и поощрять их использование. Успешная аутентификация требует, чтобы заявитель доказал владение аутентификатором и контроль над ним посредством защищенного протокола аутентификации.

4

NIST SP 800-63B-4
Июль 2025

Digital Identity Guidelines: Authentication and Authenticator Management

2.1.1. Разрешенные типы аутентификаторов

Аутентификация AAL1 ДОЛЖНА (SHALL) использовать любой из следующих типов аутентификации, которые подробнее определены в разд. 3:

  • Пароль (разд. 3.1.1): запоминаемый секрет, обычно выбираемый подписчиком
  • Секрет поиска (разд. 3.1.2): секрет, определяемый заявителем путем поиска запрошенного значения в списке, которым располагает подписчик
  • Внеполосное устройство (разд. 3.1.3): секрет, отправляемый или получаемый через отдельный канал связи с подписчиком
  • Однофакторный одноразовый пароль (OTP) (разд. 3.1.4): одноразовый секрет, полученный с устройства или из приложения, которым располагает подписчик
  • Многофакторный OTP (разд. 3.1.5): одноразовый секрет, полученный с устройства или из приложения, которым располагает подписчик и которое требует активации вторым фактором аутентификации
  • Однофакторная криптографическая аутентификация (разд. 3.1.6): доказательство владения и контроля посредством протокола аутентификации криптографического ключа, которым располагает подписчик
  • Многофакторная криптографическая аутентификация (разд. 3.1.7): доказательство владения и контроля посредством протокола аутентификации криптографического ключа, которым располагает подписчик и который требует активации вторым фактором аутентификации

2.1.2. Требования к аутентификаторам и верификаторам

Аутентификаторы, используемые на AAL1, ДОЛЖНЫ (SHALL) использовать одобренную криптографию. Иными словами, они должны использовать одобренные алгоритмы, но реализация не обязана быть валидирована по [FIPS140].

Обмен данными между заявителем и верификатором ДОЛЖЕН (SHALL) происходить через один или несколько аутентифицированных защищенных каналов.

Криптография, используемая верификаторами, эксплуатируемыми федеральными агентствами или от их имени на AAL1, ДОЛЖНА (SHALL) быть валидирована на соответствие требованиям [FIPS140] уровня 1.

2.1.3. Повторная аутентификация

Настоящие руководящие указания предусматривают два типа тайм-аутов, которые подробнее описаны в разд. 5.2:

  1. Общий тайм-аут ограничивает длительность аутентифицированного сеанса заданным периодом после аутентификации или предыдущей повторной аутентификации.
  2. Тайм-аут неактивности завершает сеанс, в котором в течение заданного периода отсутствовала активность со стороны подписчика.

5

NIST SP 800-63B-4
Июль 2025
Руководящие указания по цифровой идентификации
Аутентификация и управление аутентификаторами

Периодическая повторная аутентификация сеансов подписчика ДОЛЖНА (SHALL) выполняться, как описано в разд. 5.2. ДОЛЖЕН (SHALL) быть установлен определённый общий тайм-аут повторной аутентификации, который на уровне AAL1 СЛЕДУЕТ (SHOULD) устанавливать не более 30 дней. Тайм-аут неактивности МОЖЕТ (MAY) применяться, но на уровне AAL1 не требуется.

2.2. Уровень обеспечения аутентификации 2

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

2.2.1. Допустимые типы аутентификаторов

При AAL2 аутентификация ДОЛЖНА (SHALL) использовать либо многофакторный аутентификатор, либо сочетание двух отдельных факторов аутентификации. Для выполнения одного события аутентификации многофакторному аутентификатору требуются два фактора, например криптографически защищённому устройству со встроенным биометрическим датчиком, который требуется для активации устройства. Требования к аутентификаторам определены в разд. 3.

При использовании многофакторного аутентификатора МОЖЕТ (MAY) использоваться любой из следующих вариантов:

  • Многофакторный аутентификатор внеполосной аутентификации (разд. 3.1.3.4)
  • Многофакторный OTP (разд. 3.1.5)
  • Многофакторная криптографическая аутентификация (разд. 3.1.7)

При использовании сочетания двух однофакторных аутентификаторов сочетание ДОЛЖНО (SHALL) включать один физический аутентификатор (то есть «то, чем вы обладаете») из следующего списка совместно либо с паролем (разд. 3.1.1), либо с биометрическим сравнением:

Биометрическая характеристика сама по себе не признаётся аутентификатором. Раздел 3.2.3 требует, чтобы физический аутентификатор был аутентифицирован вместе с биометрическим сравнением. Тогда физический аутентификатор служит «тем, чем вы обладаете», тогда как биометрическое совпадение служит «тем, кем вы являетесь». Когда биометрическое сравнение используется в качестве фактора активации для многофакторного аутентификатора, сам аутентификатор служит физическим аутентификатором. Как отмечено в этом разделе, локальная проверка биометрических факторов (то есть использование многофакторного аутентификатора с биометрическим сравнением в качестве фактора активации) предпочтительнее централизованного сравнения биометрических факторов.

2.2.2. Требования к аутентификатору и верификатору

Аутентификаторы, используемые при AAL2, ДОЛЖНЫ (SHALL) использовать одобренную криптографию. Криптографические аутентификаторы, закупаемые федеральными агентствами, ДОЛЖНЫ (SHALL) быть валидированы на соответствие требованиям [FIPS140] уровня 1. Как минимум один аутентификатор, используемый при AAL2, ДОЛЖЕН (SHALL) быть устойчивым к воспроизведению, как описано в разд. 3.2.7. Аутентификация при AAL2 СЛЕДУЕТ (SHOULD) демонстрировать намерение аутентификации как минимум от одного аутентификатора, как рассматривается в разд. 3.2.8.

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

Криптография, используемая верификаторами, эксплуатируемыми федеральными агентствами или от их имени при AAL2, ДОЛЖНА (SHALL) быть валидирована на соответствие требованиям [FIPS140] уровня 1, если не указано иное.

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

2.2.3. Повторная аутентификация

Периодическая повторная аутентификация сеансов подписчика ДОЛЖНА (SHALL) выполняться, как описано в разд. 5.2. ДОЛЖЕН (SHALL) быть установлен определённый общий тайм-аут повторной аутентификации, который при AAL2 СЛЕДУЕТ (SHOULD) устанавливать не более 24 часов. Тайм-аут неактивности СЛЕДУЕТ (SHOULD) устанавливать не более 1 часа. Когда наступил тайм-аут неактивности, но общий тайм-аут ещё не наступил, верификатор МОЖЕТ (MAY) разрешить подписчику пройти повторную аутентификацию, используя только успешно подтверждённый пароль либо биометрическое сравнение совместно с секретом сеанса, как описано в разд. 5.1.

2.3. Уровень обеспечения аутентификации 3

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

2.3.1. Допустимые типы аутентификаторов

Аутентификация AAL3 ДОЛЖНА (SHALL) требовать одну из следующих комбинаций аутентификаторов:

  • Многофакторная криптографическая аутентификация (разд. 3.1.7)
  • Однофакторная криптографическая аутентификация (разд. 3.1.6), используемая совместно либо с паролем (разд. 3.1.1), либо с биометрическим сравнением

Биометрическая характеристика сама по себе не признаётся аутентификатором. Раздел 3.2.3 требует, чтобы физический аутентификатор был аутентифицирован вместе с биометрическим сравнением. Тогда физический аутентификатор служит «тем, чем вы обладаете», тогда как биометрическое совпадение служит «тем, кем вы являетесь». Когда биометрическое сравнение используется в качестве фактора активации для многофакторного аутентификатора, сам аутентификатор служит физическим аутентификатором. Как отмечено в этом разделе, локальная проверка биометрических факторов (то есть использование многофакторного аутентификатора с биометрическим сравнением в качестве фактора активации) предпочтительнее централизованного сравнения биометрических факторов.

2.3.2. Требования к аутентификатору и верификатору

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

Однофакторные и многофакторные аутентификаторы, используемые при AAL3, ДОЛЖНЫ (SHALL) быть валидированы на соответствие требованиям [FIPS140] уровня 1 или выше в целом. Как описано в разд. 3.2.12, криптографические аутентификаторы, используемые при AAL3, обязаны предоставлять аппаратно защищённую изолированную среду, чтобы предотвратить утечку или извлечение ключей аутентификации. Поскольку синхронизируемые аутентификаторы (описанные в приложении B) требуют экспортируемости закрытого ключа, синхронизируемые аутентификаторы НЕ ДОЛЖНЫ (SHALL NOT) использоваться при AAL3.

Криптография, используемая верификаторами при AAL3, ДОЛЖНА (SHALL) быть валидирована на уровне [FIPS140] 1 или выше.

Аппаратным аутентификаторам и верификаторам при AAL3 СЛЕДУЕТ (SHOULD) противостоять релевантным атакам по побочным каналам (например, анализу времени выполнения и энергопотребления).

2.3.3. Повторная аутентификация

Периодическая повторная аутентификация сеансов подписчика ДОЛЖНА (SHALL) выполняться, как описано в разд. 5.2. При AAL3 общий тайм-аут повторной аутентификации ДОЛЖЕН (SHALL) составлять не более 12 часов. Тайм-аут неактивности СЛЕДУЕТ (SHOULD) устанавливать не более 15 минут. В отличие от AAL2, требования к повторной аутентификации AAL3 совпадают с требованиями к первоначальной аутентификации при AAL3.

2.4. Общие требования

Следующие требования применяются к аутентификации на всех уровнях AAL.

2.4.1. Средства контроля безопасности

Верификатор ДОЛЖЕН (SHALL) применять надлежащим образом адаптированные средства контроля безопасности из базового набора средств контроля безопасности умеренного уровня, определённого в [SP800-53], либо из эквивалентного федерального (например, [FEDRAMP]) или отраслевого стандарта, выбранного организацией для информационных систем, приложений и онлайн-служб, для защиты которых используются настоящие руководящие указания.

2.4.2. Политика хранения записей

Верификатор ДОЛЖЕН (SHALL) соблюдать соответствующие ему политики хранения записей согласно применимым законам, нормативным актам и политикам, включая любые применимые графики хранения записей Национального управления архивов и документации (NARA). Если верификатор решает хранить записи при отсутствии обязательных требований, верификатор либо CSP или IdP, частью которого он является, ДОЛЖЕН (SHALL) провести процесс управления рисками [NISTRMF], включая оценку рисков для конфиденциальности и безопасности, чтобы определить срок хранения записей, и ДОЛЖЕН (SHALL) проинформировать подписчика об этой политике хранения.

2.4.3. Требования к конфиденциальности

Верификатор ДОЛЖЕН (SHALL) применять надлежащим образом адаптированные средства контроля конфиденциальности, определённые в [SP800-53], либо эквивалентном отраслевом стандарте.

Если CSP или IdP обрабатывают атрибуты для целей, отличных от услуг идентификации (то есть установления личности, аутентификации или утверждений об атрибутах), связанного противодействия мошенничеству либо соблюдения законов или юридических процедур, они ДОЛЖНЫ (SHALL) реализовать меры для поддержания предсказуемости и управляемости, соразмерных рискам для конфиденциальности, возникающим вследствие дополнительной обработки. Примеры таких мер включают предоставление ясного уведомления, получение согласия подписчика и обеспечение избирательного использования или раскрытия атрибутов. Когда CSP или IdP используют меры получения согласия, они НЕ ДОЛЖНЫ (SHALL NOT) делать согласие на дополнительную обработку условием предоставления услуги идентификации.

Независимо от того, является ли CSP или IdP агентством или поставщиком из частного сектора, к федеральным агентствам, предлагающим или использующим услугу аутентификации, применяются следующие требования:

  1. Агентство ДОЛЖНО (SHALL) проконсультироваться со своим Senior Agency Official for Privacy (SAOP) и провести анализ, чтобы определить, влечёт ли сбор персональной информации для выдачи или сопровождения аутентификаторов применение требований Privacy Act of 1974 [PrivacyAct] (см. разд. 7.4).
  2. Агентство ДОЛЖНО (SHALL) публиковать System of Records Notice (SORN), охватывающее такой сбор, если применимо.
  3. Агентство ДОЛЖНО (SHALL) проконсультироваться со своим SAOP и провести анализ, чтобы определить, влечёт ли сбор персональной информации для выдачи или сопровождения аутентификаторов применение требований E-Government Act of 2002 [E-Gov].
  4. Агентство ДОЛЖНО (SHALL) публиковать Privacy Impact Assessment (PIA), охватывающую такой сбор, если применимо.

2.4.4. Требования к урегулированию

Верификатор и связанный с ним CSP или IdP ДОЛЖНЫ (SHALL) предоставлять механизмы урегулирования жалоб и проблем подписчиков, возникающих в процессах аутентификации подписчика, как описано в разд. 5.6 [SP800-63]. Эти механизмы ДОЛЖНЫ (SHALL) быть легко находимыми и используемыми подписчиками. CSP или IdP ДОЛЖЕН (SHALL) оценивать эффективность механизмов при разрешении жалоб или проблем.

2.5. Сводка требований

Таблица 1 содержит ненормативную сводку требований для каждого из уровней AAL.

Таблица 1. Сводка требований по уровням AAL
ТребованиеAAL1AAL2AAL3
Допустимые типы аутентификаторов• Любой тип аутентификатора AAL2 или AAL3
• Пароль
• Секрет для поиска
• Внеполосный
• Однофакторный OTP
• Однофакторный криптографический		• Многофакторный криптографический
• Многофакторный внеполосный
• Многофакторный OTP
• Пароль или биометрическое сравнение
плюс:
– Однофакторный криптографический
– Секрет для поиска
– Внеполосный
– Однофакторный OTP		• Многофакторный криптографический
• Однофакторный криптографический
плюс:
– Пароль
– Биометрическое сравнение
Валидация FIPS 140
(государственные верификаторы и аутентификаторы)		Верификаторы
– Уровень 1		Верификаторы
– Уровень 1
Аутентификаторы
– Уровень 1 в целом		Верификаторы
– Уровень 1
Аутентификаторы
– Уровень 1 в целом
Повторная аутентификация
(рекомендуемая)		30 дней в целом24 часа в целом
1 час неактивности
Требуется один фактор		12 часов в целом
15 минут неактивности
Устойчивость к фишингуНе требуетсяРекомендуется;
должна быть доступна		Требуется
Устойчивость к воспроизведениюНе требуетсяТребуетсяТребуется
Намерение аутентификацииНе требуетсяРекомендуетсяТребуется
Экспортируемость ключаРазрешенаРазрешенаЗапрещена

NIST SP 800-63B-4 — Digital Identity Guidelines

Июль 2025 — Authentication and Authenticator Management

3. Требования к аутентификаторам и верификаторам

Этот раздел является нормативным.

В этом разделе приведены подробные требования, специфичные для каждого типа аутентификатора. За исключением требований к повторной аутентификации, указанных в разд. 2, и требования устойчивости к фишингу на AAL3, описанного в разд. 3.2.5, технические требования для каждого типа аутентификатора одинаковы независимо от уровня AAL, на котором используется аутентификатор.

В федеративных приложениях, описанных в [SP800-63C], функции аутентификации IdP близко соответствуют функциям CSP или верификатора. В последующем изложении требования, связанные с CSP, также применяются к IdP.

Во многих обстоятельствах подписчикам необходимо совместно использовать устройства, применяемые в процессах аутентификации, например семейный телефон, получающий OTP. В приложениях, доступных широкой публике, CSP НЕ СЛЕДУЕТ (SHOULD NOT) препятствовать регистрации устройства в качестве аутентификатора несколькими подписчиками. Однако они МОГУТ (MAY) устанавливать ограничения для предотвращения крупномасштабного мошенничества или неправомерного использования (например, ограничивать общее число учетных записей подписчиков, с которыми может быть зарегистрировано одно устройство).

Аутентификация, привязка аутентификатора (рассмотренная в разд. 4.1) и управление сеансом (рассмотренное в разд. 5) основаны на доказательстве владения одним или несколькими типами секретов, как показано в таблице 2.

Таблица 2. Сводка секретов (ненормативная)
Тип секретаНазначениеРаздел справки
ПарольСекрет, выбранный подписчиком и используемый в качестве фактора аутентификации3.1.1
Секрет для поискаСекрет, выданный верификатором и используемый только один раз для доказательства владения секретом3.1.2
Секрет, передаваемый по внешнему каналуКратковременный секрет, созданный верификатором и независимо отправленный на устройство подписчика для подтверждения владения им3.1.3

Продолжение на следующей странице

12

NIST SP 800-63B-4 — Digital Identity Guidelines

Июль 2025 — Authentication and Authenticator Management

Продолжение с предыдущей страницы

Тип секретаНазначениеРаздел справки
Одноразовые пароли (OTP)Секрет, созданный аутентификатором и используемый только один раз для доказательства владения аутентификатором3.1.4, 3.1.5
Секрет активацииПароль, используемый локально в качестве фактора активации для многофакторного аутентификатора3.2.10
Долговременный секрет аутентификатораСекрет, встроенный в физический аутентификатор, позволяющий ему выполнять функции аутентификации4.1
Код восстановленияСекрет, выданный подписчику, позволяющий ему восстановить учетную запись, в которой он больше не может проходить аутентификацию4.2
Секрет сеансаСекрет, выданный верификатором при аутентификации и используемый для обеспечения непрерывности аутентифицированных сеансов5.1

3.1. Требования по типам аутентификаторов

Следующие требования применяются к конкретным типам аутентификаторов.

3.1.1. Пароли

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

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

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

13

NIST SP 800-63B-4 — Digital Identity Guidelines

Июль 2025 — Authentication and Authenticator Management

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) (например, «Как звали вашего первого питомца?») или контрольные вопросы.

14

NIST SP 800-63B-4 — Digital Identity Guidelines

Июль 2025 — Authentication and Authenticator Management

  1. Верификаторы ДОЛЖНЫ (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].

15

NIST SP 800-63B-4 — Digital Identity Guidelines

Июль 2025 — Authentication and Authenticator Management

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

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

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

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

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

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

16

NIST SP 800-63B-4
Июль 2025

Руководство по цифровой идентификации
Аутентификация и управление аутентификаторами

Digital Identity Guidelines: Authentication and Authenticator Management

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

3.1.2. Секреты поиска

Аутентификатор секрета поиска представляет собой физическую или электронную запись, в которой хранится набор секретов, совместно используемых заявителем и CSP. Заявитель использует аутентификатор для поиска соответствующих секретов, необходимых для ответа на запрос верификатора. Например, верификатор может попросить заявителя предоставить определённое подмножество числовых или символьных строк, напечатанных на карточке в табличном формате. Типичное применение секретов поиска — одноразовые сохранённые коды восстановления (см. разд. 4.2.1.1), которые абонент хранит для использования в случае утраты или неисправности другого аутентификатора. Секрет поиска — это «то, чем вы владеете».

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

3.1.2.1. Аутентификаторы секретов поиска

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

3.1.2.2. Верификаторы секретов поиска

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

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

Длина секретов поиска ДОЛЖНА (SHALL) составлять не менее шести десятичных цифр (или эквивалента), как указано в разд. 3.1.2.1. Для секретов поиска, длина которых меньше установленной, действуют следующие дополнительные требования к проверке:

  • Секреты поиска, длина которых меньше минимальной криптографической стойкости, указанной в последней редакции [SP800-131A] (то есть 112 бит на дату этой публикации)
    17
    ДОЛЖНЫ (SHALL) храниться в форме с солью и хешем с использованием подходящей схемы хеширования паролей, как описано в разд. 3.1.1.2. Длина значения соли ДОЛЖНА (SHALL) составлять не менее 32 бит; оно ДОЛЖНО (SHALL) выбираться произвольно, чтобы минимизировать коллизии значений соли среди хранимых хешей. Как значение соли, так и итоговый хеш ДОЛЖНЫ (SHALL) храниться для каждого секрета поиска.
  • Верификатор ДОЛЖЕН (SHALL) реализовать механизм ограничения частоты, который эффективно ограничивает число неудачных попыток аутентификации, которые могут быть совершены для учётной записи абонента, как описано в разд. 3.2.2.

При запросе секретов поиска верификатор ДОЛЖЕН (SHALL) использовать одобренное шифрование и аутентифицированный защищённый канал.

3.1.3. Внеполосные устройства

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

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

Внеполосная аутентификация не устойчива к фишингу.

Внеполосный аутентификатор может работать одним из следующих способов:

  • Заявитель передаёт верификатору по основному каналу секрет, полученный внеполосным устройством по вторичному каналу. Например, заявитель может получить секрет (как правило, 6-значный код) на мобильное устройство и ввести его в сеанс аутентификации. Этот способ показан на рис. 1.
  • Заявитель передаёт внеполосному устройству секрет, полученный по основному каналу, для отправки верификатору по вторичному каналу. Например, заявитель может просмотреть секрет в сеансе аутентификации и либо ввести его в приложение на мобильном устройстве, либо использовать такую технологию, как штрихкод или QR-код, для выполнения передачи. Этот способ показан на рис. 2.

18

Рисунок 1; русские подписи приведены ниже
Основное устройствоВерификаторВнеполосное устройство
Ноутбук; поле для ввода секретаВерификаторСмартфон; «Приложение аутентификатора»; 314159
Основной канал: основное устройство ↔ верификатор. Вторичный канал: верификатор → внеполосное устройство. OOB-секрет: внеполосное устройство → основное устройство.
Рис. 1. Передача секрета на основное устройство
Рисунок 2; русские подписи приведены ниже
Основное устройствоВерификаторВнеполосное устройство
Ноутбук; 314159ВерификаторСмартфон; «Приложение аутентификатора»; поле для ввода секрета
Основной канал: основное устройство ↔ верификатор. Вторичный канал: внеполосное устройство → верификатор. OOB-секрет: основное устройство → внеполосное устройство.
Рис. 2. Передача секрета на внеполосное устройство

19

Примечание: Третий способ внеполосной аутентификации сравнивает секреты, полученные по основному и вторичному каналам, и запрашивает подтверждение по вторичному каналу. Этот способ более не считается приемлемым, поскольку повышает вероятность того, что абонент подтвердит запрос на аутентификацию, фактически не сравнив секреты, как требуется. Это наблюдалось при атаках типа «усталость от аутентификации», при которых атакующий направляет абоненту множество запросов на внеполосную аутентификацию, и тот может подтвердить один из них, чтобы устранить раздражающий фактор. По этой причине настоящие руководящие указания требуют передачи секрета между внеполосным устройством и основным каналом, чтобы повысить уверенность в том, что субъект активно участвует в сеансе с верификатором. Предъявление заявителю списка секретов для сравнения недостаточно для выполнения этого требования, так как заявитель может обоснованно угадать секрет из-за ограниченного размера списка, который можно предъявить.

3.1.3.1. Внеполосные аутентификаторы

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

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

Электронная почта НЕ ДОЛЖНА (SHALL NOT) использоваться для внеполосной аутентификации, поскольку она может быть уязвима к:

  • доступу с использованием только пароля;
  • перехвату при передаче или на промежуточных почтовых серверах;
  • атакам перенаправления, например вызванным подменой Domain Name System (DNS).

Коды подтверждения, которые отправляются для проверки адресов электронной почты или выдаются как коды восстановления (см. разд. 4.2.1.2), не являются процессами аутентификации и не затрагиваются приведённым выше запретом.

При взаимодействии с верификатором внеполосный аутентификатор ДОЛЖЕН (SHALL) уникально аутентифицировать себя одним из следующих способов:

20

  • Используя одобренную криптографию, установить с верификатором взаимно аутентифицированный защищённый канал (например, transport layer security (TLS) с аутентификацией клиента [RFC8446]). При связи между внеполосным аутентификатором и верификатором МОЖЕТ (MAY) использоваться доверенная промежуточная служба, в которой аутентифицируется каждая из сторон. Ключ, используемый для установления канала, ДОЛЖЕН (SHALL) быть предоставлен во взаимно аутентифицированном сеансе во время привязки аутентификатора, как описано в разд. 4.1.
  • Аутентифицироваться в публичной мобильной телефонной сети с использованием SIM-карты или эквивалентного секрета, уникально идентифицирующего абонента. Этот способ ДОЛЖЕН (SHALL) использоваться только в случае, если секрет отправляется верификатором внеполосному устройству через PSTN (то есть SMS или голосовым вызовом) либо через зашифрованную службу обмена мгновенными сообщениями.
  • Использовать проводное подключение к PSTN, на которое верификатор может позвонить и продиктовать внеполосный секрет. Для целей этого определения «проводное подключение» включает такие службы, как кабельные провайдеры, предоставляющие услуги PSTN через другие проводные среды, а также оптоволокно через аналоговые телефонные адаптеры.

Для однофакторных внеполосных аутентификаторов, если верификатор отправляет секрет на внеполосное устройство, устройству НЕ СЛЕДУЕТ (SHOULD NOT) отображать секрет аутентификации, пока оно заблокировано владельцем. Вместо этого устройству СЛЕДУЕТ (SHOULD) требовать предъявления и проверки PIN-кода, кода доступа или биометрической характеристики для просмотра секрета. Однако аутентификаторам СЛЕДУЕТ (SHOULD) указывать на получение секрета аутентификации на заблокированном устройстве.

Если внеполосный аутентификатор запрашивает подтверждение по вторичному каналу связи, а не путём предъявления секрета, который заявитель передаёт в основной канал связи, он ДОЛЖЕН (SHALL) принять передачу секрета из основного канала и отправить его верификатору по вторичному каналу, чтобы связать подтверждение с транзакцией аутентификации. Заявитель МОЖЕТ (MAY) выполнить передачу вручную либо с помощью представления, такого как штрихкод или код быстрого отклика (QR).

3.1.3.2. Верификаторы внеполосных аутентификаторов

Верификатор ожидает установления аутентифицированного защищённого канала с внеполосным аутентификатором и проверяет его идентифицирующий ключ. Верификатор НЕ ДОЛЖЕН (SHALL NOT) хранить сам идентифицирующий ключ, но ДОЛЖЕН (SHALL) использовать метод проверки (например, одобренную хеш-функцию или доказательство владения идентифицирующим ключом), чтобы уникально идентифицировать аутентификатор. После аутентификации верификатор передаёт секрет аутентификации аутентификатору. Соединение с внеполосным аутентификатором МОЖЕТ (MAY) инициироваться вручную или запускаться механизмом, например push-уведомлением.

В зависимости от типа внеполосного аутентификатора ДОЛЖНО (SHALL) произойти одно из следующего:

  • Передача секрета из вторичного канала в основной канал. Как показано на рис. 1, верификатор МОЖЕТ (MAY) подать сигнал устройству, содержащему принадлежащий абоненту аутентификатор, чтобы указать готовность к аутентификации.
    21

NIST SP 800-63B-4. Руководящие указания по цифровой идентификации

Июль 2025. Аутентификация и управление аутентификаторами

Digital Identity Guidelines: Authentication and Authenticator Management

Затем он ДОЛЖЕН (SHALL) передать случайный секрет внеполосному аутентификатору и дождаться возврата секрета через основной канал связи.

  • Передача секрета из основного во вторичный канал. Как показано на рис. 2, верификатор ДОЛЖЕН (SHALL) передать заявителю случайный секрет аутентификации через основной канал. Затем он ДОЛЖЕН (SHALL) дождаться возврата секрета через вторичный канал от внеполосного аутентификатора заявителя. Верификатор МОЖЕТ (MAY) дополнительно отобразить адрес, например номер телефона или адрес VoIP, который заявитель будет использовать для адресации своего ответа верификатору.

Во всех случаях аутентификация ДОЛЖНА (SHALL) считаться недействительной, если она не завершена в течение 10 минут. Верификаторы ДОЛЖНЫ (SHALL) принимать заданный секрет аутентификации как действительный только один раз в течение периода действия для обеспечения устойчивости к повторному воспроизведению, как описано в разд. 3.2.7.

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

Внеполосным верификаторам, отправляющим push-уведомление на устройство подписчика, СЛЕДУЕТ (SHOULD) реализовать разумное ограничение частоты или общего числа push-уведомлений, которые будут отправлены с момента последней успешной аутентификации.

Дополнительные требования к верификации, относящиеся к PSTN, см. в разд. 3.1.3.3.

3.1.3.3. Аутентификация с использованием коммутируемой телефонной сети общего пользования

Использование PSTN для внеполосной верификации ограничено, как описано в этом разделе, и ДОЛЖНО (SHALL) удовлетворять требованиям разд. 3.2.9. Установка или изменение предварительно зарегистрированного телефонного номера считается привязкой нового аутентификатора и ДОЛЖНА (SHALL) происходить только так, как описано в разд. 4.1.2.

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

Верификаторам СЛЕДУЕТ (SHOULD) учитывать индикаторы риска (например, замену устройства, замену SIM-карты, перенос номера, иное аномальное поведение) до использования PSTN для доставки внеполосного секрета аутентификации.

22

NIST SP 800-63B-4. Руководящие указания по цифровой идентификации

Июль 2025. Аутентификация и управление аутентификаторами

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

3.1.3.4. Многофакторные внеполосные аутентификаторы

Многофакторные внеполосные аутентификаторы работают аналогично однофакторным внеполосным аутентификаторам (см. разд. 3.1.3.1). Однако они требуют предъявления и проверки фактора активации (то есть пароля или биометрической характеристики), прежде чем позволить заявителю завершить транзакцию аутентификации (то есть до получения доступа к секрету аутентификации либо его ввода в соответствии с используемым потоком аутентификации). Каждое использование аутентификатора ДОЛЖНО (SHALL) требовать предъявления фактора активации.

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

3.1.4. Однофакторные OTP

Однофакторный OTP генерирует одноразовые пароли (OTP). Эта категория включает аппаратные устройства и программные генераторы OTP, установленные на устройствах, таких как мобильные телефоны. Эти аутентификаторы имеют встроенный секрет, который используется в качестве начального значения для генерации OTP, и не требуют активации посредством второго фактора. OTP отображается на аутентификаторе и вручную вводится для передачи верификатору, тем самым доказывая владение аутентификатором и контроль над ним. Однофакторный OTP-аутентификатор — это «то, чем вы владеете».

Однофакторные OTP сходны с аутентификаторами секретов поиска, за исключением того, что секреты криптографически и независимо генерируются аутентификатором и верификатором и сравниваются верификатором. Секрет вычисляется на основе nonce, который может основываться на времени или на счётчике в аутентификаторе и верификаторе.

Аутентификация OTP не устойчива к фишингу. Валидация [FIPS140] OTP-аутентификаторов и верификаторов не требуется.

3.1.4.1. Однофакторные OTP-аутентификаторы

Однофакторные OTP-аутентификаторы и верификаторы содержат два постоянных значения: 1) симметричный ключ, сохраняющийся в течение срока службы аутентификатора, и 2) nonce, который либо изменяется при каждом использовании аутентификатора, либо основан на часах реального времени.

23

NIST SP 800-63B-4. Руководящие указания по цифровой идентификации

Июль 2025. Аутентификация и управление аутентификаторами

Секретный ключ и его алгоритм ДОЛЖНЫ (SHALL) обеспечивать как минимум минимальную стойкость, указанную в последней редакции [SP800-131A] (то есть 112 битов на дату этой публикации). Nonce ДОЛЖЕН (SHALL) иметь достаточную длину, чтобы обеспечить его уникальность для каждой операции аутентификатора в течение срока его службы. Если подписчику необходимо сменить устройство, на котором размещён программный OTP-аутентификатор, ему СЛЕДУЕТ (SHOULD) привязать приложение аутентификатора на новом устройстве к своей учётной записи подписчика, как описано в разд. 4.1.2, и сделать недействительным приложение аутентификатора, которое больше не будет использоваться. В качестве альтернативы подписчик МОЖЕТ (MAY) экспортировать секретный ключ и сохранить его в среде синхронизации, соответствующей требованиям приложения B.2, а затем получить ключ на новом устройстве.

Выходные данные аутентификатора получают с использованием утверждённого блочного шифра или хеш-функции для безопасного объединения ключа и nonce. По согласованию с верификатором аутентификатор МОЖЕТ (MAY) усечь свои выходные данные вплоть до шести десятичных цифр (или эквивалентного представления). Если nonce, используемый для генерации выходных данных аутентификатора, основан на часах реального времени, nonce ДОЛЖЕН (SHALL) изменяться не реже одного раза в каждые две минуты.

3.1.4.2. Верификаторы однофакторных OTP

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

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

Верификатор ДОЛЖЕН (SHALL) использовать утверждённое шифрование и аутентифицированный защищённый канал при получении OTP. Верификаторы ДОЛЖНЫ (SHALL) принимать заданный OTP только один раз, пока он действителен, для обеспечения устойчивости к повторному воспроизведению, как описано в разд. 3.2.7. Если аутентификация заявителя отклонена вследствие повторного использования OTP, верификаторы МОГУТ (MAY) предупредить заявителя, если злоумышленник смог аутентифицироваться заранее. Верификаторы МОГУТ (MAY) также предупредить подписчика в существующем сеансе о попытке повторного использования OTP.

OTP, основанные на времени [TOTP], ДОЛЖНЫ (SHALL) иметь определённый срок действия, определяемый ожидаемым дрейфом часов аутентификатора в любом направлении в течение срока его службы, плюс допуск на сетевую задержку и ввод OTP заявителем.

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

24

NIST SP 800-63B-4. Руководящие указания по цифровой идентификации

Июль 2025. Аутентификация и управление аутентификаторами

3.1.5. Многофакторные OTP

Многофакторный OTP генерирует одноразовые пароли для аутентификации после ввода фактора активации. Сюда входят аппаратные устройства и программные генераторы OTP, установленные на мобильных телефонах и подобных устройствах. Второй фактор аутентификации может предоставляться посредством встроенной клавиатуры, встроенного биометрического считывателя (например, отпечатка пальца) или прямого компьютерного интерфейса (например, порта универсальной последовательной шины [USB]). OTP отображается на аутентификаторе и вручную вводится для передачи верификатору. Многофакторный OTP-аутентификатор — это «то, чем вы владеете», активируемое либо «тем, что вы знаете», либо «тем, чем вы являетесь».

Аутентификация OTP не устойчива к фишингу. Валидация [FIPS140] OTP-аутентификаторов и верификаторов не требуется.

3.1.5.1. Многофакторные OTP-аутентификаторы

Многофакторные OTP-аутентификаторы работают аналогично однофакторным OTP-аутентификаторам (см. разд. 3.1.4.1), за исключением того, что для получения OTP от аутентификатора они требуют предъявления и проверки фактора активации (то есть пароля или биометрической характеристики). Каждое использование аутентификатора ДОЛЖНО (SHALL) требовать ввода фактора активации.

Помимо информации для активации, многофакторные OTP-аутентификаторы и верификаторы содержат два постоянных значения: 1) симметричный ключ, сохраняющийся в течение срока службы аутентификатора, и 2) nonce, который либо изменяется при каждом использовании аутентификатора, либо основан на часах реального времени.

Секретный ключ и его алгоритм ДОЛЖНЫ (SHALL) обеспечивать как минимум минимальную стойкость, указанную в последней редакции [SP800-131A] (то есть 112 битов на дату этой публикации). Nonce ДОЛЖЕН (SHALL) иметь достаточную длину, чтобы обеспечить его уникальность для каждой операции аутентификатора в течение срока его службы. Если подписчику необходимо сменить устройство, на котором размещён программный OTP-аутентификатор, ему СЛЕДУЕТ (SHOULD) привязать приложение аутентификатора на новом устройстве к своей учётной записи подписчика, как описано в разд. 4.1.2, и сделать недействительным приложение аутентификатора, которое больше не будет использоваться. В качестве альтернативы подписчик МОЖЕТ (MAY) экспортировать секретный ключ и сохранить его в среде синхронизации, соответствующей требованиям приложения B.2, и получить ключ на новом устройстве.

Выходные данные аутентификатора получают с использованием утверждённого криптографического блочного шифра или хеш-функции для безопасного объединения ключа и nonce. По согласованию с верификатором аутентификатор МОЖЕТ (MAY) усечь свои выходные данные вплоть до шести десятичных цифр или эквивалента. Если nonce, используемый для генерации выходных данных аутентификатора, основан на часах реального времени, nonce ДОЛЖЕН (SHALL) изменяться не реже одного раза в каждые две минуты.

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

25

NIST SP 800-63B-4
Июль 2025
Руководящие указания по цифровой идентификации
Аутентификация и управление аутентификаторами

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

3.1.5.2. Верификаторы многофакторных OTP

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

При привязке аутентификатора многофакторных OTP к учётной записи подписчика верификатор или связанный CSP ДОЛЖЕН (SHALL) использовать одобренную криптографию для установления ключей, чтобы сгенерировать и обменяться ключами либо получить секреты, необходимые для дублирования вывода аутентификатора.

При получении OTP верификатор ДОЛЖЕН (SHALL) использовать одобренное шифрование и аутентифицированный защищённый канал. Для обеспечения устойчивости к повторному воспроизведению, как описано в разд. 3.2.7, верификаторы ДОЛЖНЫ (SHALL) принимать данный OTP лишь один раз в течение срока его действия. Если аутентификация заявителя отклонена вследствие повторного использования OTP, верификаторы МОГУТ (MAY) предупредить заявителя, если злоумышленник смог пройти аутентификацию заранее. Верификаторы также МОГУТ (MAY) предупредить подписчика в существующем сеансе о попытке повторного использования OTP.

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

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

3.1.6. Однофакторная криптографическая аутентификация

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

Криптографическая аутентификация устойчива к фишингу, если она соответствует дополнительным требованиям разд. 3.2.5.

26

3.1.6.1. Однофакторные криптографические аутентификаторы

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

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

Внешние (то есть невстроенные) криптографические аутентификаторы ДОЛЖНЫ (SHALL) соответствовать требованиям к подключаемым аутентификаторам из разд. 3.2.11.

Как требуется в разд. 2.3.2, однофакторные криптографические аутентификаторы, используемые на AAL3, должны соответствовать требованиям намерения аутентификации из разд. 3.2.8.

3.1.6.2. Однофакторные криптографические верификаторы

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

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

Ключ аутентификации и его алгоритм ДОЛЖНЫ (SHALL) обеспечивать как минимум минимальную криптографическую стойкость, указанную в последней редакции [SP800-131A] (то есть 112 бит на дату настоящей публикации). Nonce вызова ДОЛЖЕН (SHALL) иметь длину не менее 64 бит и ДОЛЖЕН (SHALL) быть либо уникальным в течение срока эксплуатации аутентификатора, либо статистически уникальным (то есть сгенерированным с использованием одобренного генератора случайных битов, как описано в разд. 3.2.12). Операция проверки ДОЛЖНА (SHALL) использовать одобренную криптографию.

3.1.7. Многофакторная криптографическая аутентификация

Многофакторная криптографическая аутентификация использует протокол аутентификации, чтобы доказать владение ключом аутентификации и контроль над ним, требующим активации посредством
27
второго фактора аутентификации. В зависимости от необходимой стойкости аутентификации ключ аутентификации может храниться способом, обеспечивающим доступ к нему конечной точке, проходящей аутентификацию, либо в отдельном непосредственно подключённом процессоре или устройстве. Вывод аутентификатора в значительной степени зависит от используемого конкретного криптографического протокола, но обычно представляет собой некоторый тип подписанного сообщения. Многофакторный криптографический аутентификатор — это «то, что у вас есть», и он активируется фактором активации, представляющим либо «то, что вы знаете», либо «то, кем вы являетесь». Многофакторные криптографические аутентификаторы, используемые на AAL3, ДОЛЖНЫ (SHALL) использовать криптографию с открытым ключом для защиты секретов аутентификации от компрометации верификатора.

Криптографическая аутентификация устойчива к фишингу, если она соответствует дополнительным требованиям разд. 3.2.5.

3.1.7.1. Многофакторные криптографические аутентификаторы

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

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

3.1.7.2. Многофакторные криптографические верификаторы

Требования к многофакторному криптографическому верификатору идентичны требованиям к однофакторному криптографическому верификатору, описанным в разд. 3.1.6.2. Некоторые многофакторные аутентификаторы включают флаги, указывающие, был ли использован фактор активации. Если такой флаг присутствует и указывает, что фактор активации не был использован, аутентификация
28
ДОЛЖНА (SHALL) рассматриваться как однофакторная. В противном случае проверка вывода многофакторного криптографического аутентификатора указывает, что фактор активации был использован.

3.1.7.3. Использование с кошельками под управлением подписчика

Конкретной формой многофакторной криптографической аутентификации является кошелёк под управлением подписчика на устройстве подписчика, как описано в разд. 5 [SP800-63C]. После того как заявитель впервые разблокирует кошелёк с помощью фактора активации, процесс аутентификации использует протокол федерации, как подробно описано в [SP800-63C]. Содержимое утверждения и требования к его предъявлению в протоколе федерации обеспечивают характеристики безопасности, требуемые от криптографических аутентификаторов. Поэтому кошельки под управлением подписчика на устройстве подписчика могут рассматриваться как многофакторные аутентификаторы благодаря фактору активации, а также предъявлению и валидации утверждения, сформированного кошельком.

Кошельки, размещённые в облаке, не считаются криптографическими многофакторными аутентификаторами, поскольку доступ поддерживается посредством аутентификации через интернет, а не локально. Вся информация аутентификации от размещённых кошельков обрабатывается как утверждение, как рассматривается в разд. 5 [SP800-63C].

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

Процессы аутентификации с использованием кошельков под управлением подписчика ДОЛЖНЫ (SHALL) применяться вместе с процессом федерации, как подробно описано в разд. 5 [SP800-63C]. Подписанные утверждения с ограничением аудитории, сформированные кошельками под управлением подписчика, считаются устойчивыми к фишингу, поскольку предотвращают использование легитимным RP утверждения, предъявленного RP-самозванцу. Утверждения, не имеющие действительной подписи от кошелька или ограничения аудитории, НЕ ДОЛЖНЫ (SHALL NOT) считаться устойчивыми к фишингу. Утверждения также ДОЛЖНЫ (SHALL) включать достаточную информацию для определения характера метода активации, использованного для активации кошелька.

3.1.7.4. Синхронизируемые аутентификаторы

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

29

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

3.2. Общие требования к аутентификаторам

Следующие требования применяются ко всем типам аутентификации.

3.2.1. Физические аутентификаторы

CSP ДОЛЖНЫ (SHALL) предоставлять абоненту инструкции по надлежащей защите аутентификатора от кражи или утраты. CSP ДОЛЖЕН (SHALL) предоставлять механизм для аннулирования1 аутентификатора немедленно после уведомления абонента о предполагаемой утрате, краже или компрометации аутентификатора.

Владение физическим аутентификатором и контроль над ним основываются на доказательстве владения секретом, связанным с аутентификатором. Когда встроенный секрет (как правило, сертификат и связанный с ним закрытый ключ) находится в конечной точке, её «идентичность устройства» может считаться физическим аутентификатором. Однако для этого требуется защищённый протокол аутентификации, подходящий для аутентифицируемого AAL. Файлы cookie браузера не удовлетворяют этому требованию, за исключением кратковременных секретов для поддержания сеанса (не аутентификации), как описано в разд. 5.1.1.

3.2.2. Ограничение частоты (троттлинг)

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

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

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

  • требование к заявителю пройти проверку на обнаружение и противодействие ботам до попытки аутентификации;
  • требование к заявителю после неудачной попытки выждать период времени, который увеличивается по мере приближения учётной записи абонента к максимально допустимому числу последовательных неудачных попыток (например, от 30 секунд до одного часа);
  • использование других основанных на риске или адаптивных методов аутентификации для выявления поведения заявителя, находящегося в пределах или за пределами типичных норм (например, использования IP-адреса заявителя, геолокации, временных характеристик шаблонов запросов или метаданных браузера).

Когда абонент успешно аутентифицируется, верификатору СЛЕДУЕТ (SHOULD) игнорировать все предшествующие неудачные попытки для аутентификаторов, использованных при успешной аутентификации.

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

3.2.3. Использование биометрии

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

Биометрические сравнения основаны на измерении, полученном от биометрического датчика (например, камеры или считывателя отпечатков пальцев). Такое измерение подвержено шуму и вариациям предъявления, которые требуют установки порога принятия на основе различий между измеренной биометрической характеристикой и эталоном, с которым она сравнивается. Вследствие этих факторов существует некоторая вероятность того, что сравнение не даст совпадения; она называется коэффициентом ложного несовпадения (FNMR). Аналогично, существует вероятность того, что сравнение с самозванцем даст совпадение; она называется коэффициентом ложного совпадения (FMR). Высококачественная биометрическая система имеет как очень низкий FMR, так и FNMR. Выбранный порог обычно делает акцент на низком FMR для максимизации безопасности, поскольку ложные несовпадения часто могут быть смягчены повторением измерения или использованием альтернативного метода аутентификации.

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

  • биометрический FMR сам по себе не обеспечивает достаточной уверенности в аутентификации абонента, поскольку не учитывает активные атаки выдачи себя за другое лицо;
  • биометрическое сравнение является вероятностным, тогда как другие факторы аутентификации являются детерминированными;
  • схемы защиты биометрических шаблонов предоставляют способ отзыва биометрических характеристик, делающий их сопоставимыми с другими факторами аутентификации (например, сертификатами PKI, паролями). Однако доступность таких решений ограничена;
  • биометрические характеристики не являются секретами. Их часто можно получить в сети или иным образом без согласия. Изображение лица можно получить, сделав фотографию; скрытые отпечатки пальцев можно получить с предметов, к которым прикасается человек; а рисунки радужной оболочки можно захватить камерами высокого разрешения. Хотя технологии обнаружения атак предъявления (PAD) могут смягчать риски таких типов атак, требуется дополнительное доверие к датчику или биометрической обработке, чтобы гарантировать работу PAD в соответствии с потребностями CSP и абонента;
  • использование биометрических характеристик, особенно при их хранении для централизованной проверки, создаёт новые проблемы конфиденциальности, которые подробнее рассматриваются в разд. 7.

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

Биометрия ДОЛЖНА (SHALL) использоваться только как часть многофакторной аутентификации с физическим аутентификатором (то есть «тем, что у вас есть»). Биометрическая характеристика ДОЛЖНА (SHALL) предъявляться и сравниваться при каждой операции аутентификации. Абоненту ДОЛЖЕН (SHALL) всегда предоставляться альтернативный небиометрический вариант аутентификации. Биометрические данные ДОЛЖНЫ (SHALL) рассматриваться и защищаться как чувствительная персональная информация.

3.2.3.1. Точность биометрии

Биометрическая система ДОЛЖНА (SHALL) работать с FMR [ISO/IEC2382-37] один на 10000 или лучше для всех демографических групп. Рассматриваемые демографические категории ДОЛЖНЫ (SHALL) включать пол и тон кожи, когда эти факторы влияют на показатели биометрической системы. Этот FMR ДОЛЖЕН (SHALL) достигаться в условиях атаки, соответствующей требованиям (то есть попытки самозванца без усилий), как определено в [ISO/IEC30107-1]. Биометрической системе СЛЕДУЕТ (SHOULD) демонстрировать коэффициент ложного несовпадения (FNMR) менее 5 %. Показатели биометрической системы ДОЛЖНЫ (SHALL) испытываться в соответствии с [ISO/IEC19795-1]. Биометрическая система ДОЛЖНА (SHALL) быть настроена с фиксированным порогом; изменять порог для каждой демографической группы неосуществимо.

3.2.3.2. Обнаружение атак предъявления

Биометрической системе СЛЕДУЕТ (SHOULD) реализовывать PAD для модальностей радужной оболочки и отпечатков пальцев и ДОЛЖНА (SHALL) реализовывать PAD для распознавания лиц. Биометрическое сравнение на основе голоса НЕ ДОЛЖНО (SHALL NOT) использоваться. Тестирование биометрической системы для развёртывания СЛЕДУЕТ (SHOULD) демонстрировать коэффициент принятия предъявления при атаке самозванца (IAPAR) менее 0.07. Устойчивость к атакам предъявления СЛЕДУЕТ (SHOULD) испытывать в соответствии с пунктом 13 [ISO/IEC30107-3], следуя методологиям оценки безопасности из [ISO/IEC19792] или [ISO/IEC19989-1] и [ISO/IEC19989-3]. Решение PAD МОЖЕТ (MAY) приниматься либо локально на устройстве заявителя, либо центральным верификатором.

3.2.3.3. Обнаружение атак внедрения

Биометрическая система ДОЛЖНА (SHALL) допускать не более пяти последовательных неудачных попыток аутентификации или 10 последовательных неудачных попыток, если PAD реализовано и отвечает приведённым выше требованиям. После достижения этого предела биометрический аутентификатор ДОЛЖЕН (SHALL) устанавливать задержку не менее 30 секунд перед каждой последующей попыткой при общем пределе не более 50 последовательных неудачных попыток аутентификации или 100, если PAD реализовано вследствие смягчения атак предъявления. После достижения общего предела биометрическая система ДОЛЖНА (SHALL) отключить биометрическую аутентификацию и предложить другой фактор (например, другую биометрическую модальность или секрет активации, если он не является обязательным фактором), если такой альтернативный метод уже доступен. Эти пределы являются верхними границами, и ведомства МОГУТ (MAY) принимать основанные на риске решения об установлении более низких пределов.

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

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

Биометрическое сравнение может выполняться локально на устройстве, используемом заявителем, или у центрального верификатора. Поскольку потенциал атак в более крупном масштабе выше у центральных верификаторов, сравнение СЛЕДУЕТ (SHOULD) выполнять локально.

Предъявление биометрического фактора для активации аутентификатора ДОЛЖНО (SHALL) быть отдельной операцией от разблокирования хост-устройства (например, смартфона). Однако тот же фактор активации, который используется для разблокирования хост-устройства, МОЖЕТ (MAY) использоваться в операции аутентификации. Ведомства МОГУТ (MAY) снизить это требование для аутентификаторов, управляемых CSP или от его имени (например, посредством управления мобильными устройствами), если для них установлены короткие задаваемые ведомством тайм-ауты неактивности и они имеют биометрические системы, отвечающие приведённым выше требованиям.

Если сравнение выполняется централизованно:

  • датчик или конечная точка ДОЛЖНЫ (SHALL) быть аутентифицированы до захвата биометрического образца у заявителя. Верификатор МОЖЕТ (MAY) ограничить использование централизованно хранимого биометрического шаблона конкретными датчиками или классами датчиков (например, производителями или моделями датчиков);
  • ДОЛЖНЫ (SHALL) быть реализованы надлежащие меры контроля (например, шифрование и меры контроля доступа) для чувствительной персональной информации.

1Аннулирование может принимать несколько форм, включая отзыв аутентификатора на основе инфраструктуры открытых ключей (PKI) и удаление из учётной записи абонента.

NIST SP 800-63B-4
Digital Identity Guidelines
July 2025
Authentication and Authenticator Management

  • Между датчиком (или конечной точкой, содержащей датчик, устойчивый к подмене датчика) и верификатором ДОЛЖЕН (SHALL) быть установлен аутентифицированный защищённый канал. Вся передача биометрической информации ДОЛЖНА (SHALL) осуществляться по этому аутентифицированному защищённому каналу.
3.2.3.4. Использование биометрических образцов

Биометрические образцы, собранные в процессе аутентификации, МОГУТ (MAY) использоваться локально в аутентификаторе или верификаторе, выполняющем биометрическое сравнение, для обновления шаблонов с целью компенсации изменений характеристик подписчика или — при явно выраженном согласии подписчика — для иных исследовательских целей. Биометрические образцы и любые иные биометрические данные, полученные из них, ДОЛЖНЫ (SHALL) быть удалены немедленно после получения любых данных для адаптации или исследования. Предельный допустимый срок для адаптации ДОЛЖЕН (SHALL) быть установлен и обеспечиваться аутентификатором или CSP.

3.2.4. Аттестация

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

Информация, передаваемая посредством аттестации, МОЖЕТ (MAY) включать в себя, помимо прочего:

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

Аттестации ДОЛЖНЫ (SHALL) быть подписаны с использованием цифровой подписи, обеспечивающей как минимум минимальную стойкость безопасности, указанную в последней редакции [SP800-131A] (то есть 112 бит на дату настоящей публикации).

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

2 Федеральные корпоративные системы включают системы, считающиеся входящими в сферу действия руководства PIV, такие как государственные подрядчики, государственные служащие и партнёры по выполнению задач. Они не включают варианты использования «государство — потребитель» или варианты использования, ориентированные на общественность.

3.2.5. Устойчивость к фишингу

Фишинговые атаки, ранее называвшиеся в SP 800-63B «имитацией верификатора», представляют собой попытки мошеннических верификаторов и RP ввести ничего не подозревающего заявителя в заблуждение, чтобы тот предъявил аутентификатор самозванцу. В некоторых предыдущих версиях SP 800-63 протоколы, устойчивые к фишинговым атакам, также назывались «строго устойчивыми к MitM».

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

Для обеспечения устойчивости к фишингу там, где это требуется, ДОЛЖНЫ (SHALL) использоваться одобренные криптографические алгоритмы. Ключи, используемые для этой цели, ДОЛЖНЫ (SHALL) обеспечивать как минимум минимальную стойкость безопасности, указанную в последней редакции [SP800-131A] (то есть 112 бит на дату настоящей публикации).

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

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

3.2.5.1. Привязка к каналу

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

Примером устойчивого к фишингу протокола аутентификации, использующего привязку к каналу, является TLS с аутентификацией клиента [RFC8446], в котором клиент подписывает выходные данные аутентификатора вместе с более ранними сообщениями протокола, уникальными для конкретного согласовываемого TLS-соединения. Карты проверки персональной идентичности (PIV) и карты общего доступа (CAC), использующие TLS с аутентификацией клиента, обеспечивают устойчивость к фишингу посредством привязки к каналу.

3.2.5.2. Привязка к имени верификатора

Протокол аутентификации с привязкой к имени верификатора ДОЛЖЕН (SHALL) установить аутентифицированный защищённый канал с верификатором. Затем протокол ДОЛЖЕН (SHALL) сгенерировать выходные данные аутентификатора, криптографически привязанные к идентификатору верификатора, который аутентифицируется как часть протокола. В случае идентификаторов DNS идентификатором верификатора ДОЛЖНО (SHALL) быть либо аутентифицированное имя хоста верификатора, либо родительский домен, находящийся как минимум на один уровень ниже публичного суффикса [PSL], связанного с этим именем хоста. Привязка МОЖЕТ (MAY) быть установлена выбором связанного секрета аутентификатора, выведением секрета аутентификатора с использованием идентификатора верификатора, криптографическим подписанием выходных данных аутентификатора вместе с идентификатором верификатора или применением аналогичных криптографически защищённых средств.

WebAuthn [WebAuthn], используемый аутентификаторами, реализующими спецификации Fast Identity Online 2 (FIDO2) [FIDO2], является примером стандарта, который обеспечивает устойчивость к фишингу посредством привязки к имени верификатора путём выбора секрета аутентификатора на основе аутентифицированного доменного имени верификатора.

3.2.6. Связь верификатора с CSP или IdP

Если верификатор и CSP или IdP являются отдельными сущностями (как показано пунктирной линией на рис. 3 в [SP800-63]), связь между верификатором и CSP или IdP ДОЛЖНА (SHALL) осуществляться через взаимно аутентифицированный защищённый канал (например, TLS-соединение с аутентификацией клиента) с использованием одобренной криптографии.

3.2.7. Устойчивость к повторному воспроизведению

Процесс аутентификации устойчив к атакам повторного воспроизведения, если успешной аутентификации практически невозможно достичь путём записи и повторного воспроизведения предыдущего сообщения аутентификации. Устойчивость к повторному воспроизведению дополняет устойчивый к повторному воспроизведению характер протоколов аутентифицированных защищённых каналов, поскольку выходные данные могут быть похищены до входа в защищённый канал. Протоколы, использующие nonce или запросы-вызовы для подтверждения «свежести» транзакции, устойчивы к атакам повторного воспроизведения, поскольку верификатор легко обнаружит повторное воспроизведение старых сообщений протокола: они не будут содержать соответствующих nonce или данных о своевременности. Примеры аутентификаторов, устойчивых к повторному воспроизведению, включают OTP-аутентификаторы, криптографические аутентификаторы и секреты поиска.

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

3.2.8. Намерение аутентификации

Процесс аутентификации демонстрирует намерение, если он требует, чтобы заявитель явно отвечал на каждый запрос аутентификации или повторной аутентификации. Цель намерения аутентификации состоит в том, чтобы затруднить использование аутентификаторов (например, многофакторных криптографических аутентификаторов) без ведома заявителя, например вредоносным ПО на конечной точке. Сам аутентификатор ДОЛЖЕН (SHALL) устанавливать намерение аутентификации. Многофакторные аутентификаторы МОГУТ (MAY) устанавливать намерение посредством повторного ввода фактора активации для аутентификатора.

Намерение аутентификации МОЖЕТ (MAY) быть установлено несколькими способами. Процессы аутентификации, требующие вмешательства заявителя, могут использоваться для подтверждения намерения (например, заявитель вводит выходные данные аутентификатора из OTP-аутентификатора). Криптографические аутентификаторы, требующие действия заявителя для каждой операции аутентификации или повторной аутентификации, также могут использоваться для установления намерения (например, нажатием кнопки или повторной вставкой).

Предъявление биометрических характеристик не всегда устанавливает намерение аутентификации. Например, использование фронтальной камеры мобильного телефона для захвата биометрии лица не обязательно означает намерение, поскольку можно разумно ожидать, что она захватит изображение лица, когда устройство используется для других, не связанных с аутентификацией целей. В таких сценариях для установления намерения аутентификации ДОЛЖЕН (SHALL) быть предоставлен явный механизм (например, касание программной или физической кнопки).

3.2.9. Ограниченные аутентификаторы

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

Чтобы учитывать эти изменения характеристик аутентификаторов, NIST налагает дополнительные ограничения на типы аутентификаторов либо на конкретные классы или реализации типа аутентификатора. Хотя они представляют менее безопасный подход к многофакторной аутентификации, ограниченные аутентификаторы остаются необходимыми для некоторых приложений «государство — общественность». На момент публикации настоящих руководств существует один ограниченный аутентификатор: использование PSTN для внеполосной аутентификации, как описано в разд. 3.1.3.3.

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

NIST SP 800-63B-4

Digital Identity Guidelines: Authentication and Authenticator Management

Июль 2025

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

  1. Предоставить подписчикам по меньшей мере один альтернативный аутентификатор, который не является ограниченным и может использоваться для аутентификации при требуемом AAL.
  2. Предоставить подписчикам содержательное уведомление о рисках безопасности ограниченного аутентификатора и доступности неограниченных альтернатив.
  3. Учесть в своей оценке рисков любые дополнительные риски для подписчиков и RP.
  4. Разработать план миграции на случай, если ограниченный аутентификатор не будет приемлем в будущем, и включить этот план миграции в своё Digital Identity Acceptance Statement (см. разд. 3.4.4 [SP800-63]).

3.2.10. Секреты активации

Пароль, используемый локально в качестве фактора активации для многофакторного аутентификатора, называется секретом активации. Секрет активации используется для получения доступа к сохранённому ключу аутентификации. Во всех случаях секрет активации ДОЛЖЕН (SHALL) оставаться внутри аутентификатора и связанной с ним пользовательской конечной точки.

Аутентификаторы, использующие секреты активации, ДОЛЖНЫ (SHALL) требовать, чтобы длина секретов составляла не менее четырёх символов, и СЛЕДУЕТ (SHOULD) требовать, чтобы длина секретов составляла не менее шести символов. Секреты активации МОГУТ (MAY) состоять исключительно из цифр (то есть быть PIN). В противном случае в секретах активации СЛЕДУЕТ (SHOULD) разрешать все печатаемые символы ASCII [RFC20], символ пробела и символы Unicode [ISO/ISC 10646]. Аутентификатор или его средства управления СЛЕДУЕТ (SHOULD) реализовать блок-лист, чтобы препятствовать выбору подписчиками широко используемых секретов активации (например, 123456).

Аутентификатор или верификатор ДОЛЖЕН (SHALL) реализовать механизм ограничения повторных попыток, который ограничивает число последовательных неудачных попыток активации с использованием аутентификатора значением не более 10. Если ввод неверного секрета активации приводит к тому, что аутентификатор выдаёт недопустимый результат центральному верификатору, верификатор МОЖЕТ (MAY) реализовать этот механизм ограничения повторных попыток. В противном случае ограничение повторных попыток ДОЛЖНО (SHALL) быть реализовано в аутентификаторе. После достижения предела попыток аутентификатор ДОЛЖЕН (SHALL) быть отключён, и для аутентификации ДОЛЖЕН (SHALL) потребоваться другой аутентификатор.

Для аутентификаторов, которые могут использоваться при AAL3, проверка секретов активации ДОЛЖНА (SHALL) выполняться в аппаратно защищённой среде (например, в защищённом элементе, TPM или TEE). При AAL2, если аппаратно защищённая среда не используется, аутентификатор ДОЛЖЕН (SHALL) использовать секрет активации для получения ключа, используемого для расшифрования ключа аутентификации.

Передача фактора активации ДОЛЖНА (SHALL) быть отдельной операцией от разблокировки хост-устройства (например, смартфона). Однако тот же фактор активации, который используется для разблокировки хост-устройства, МОЖЕТ (MAY) использоваться в операции аутентификации. Агентства МОГУТ (MAY) смягчить это требование для аутентификаторов, которыми управляет CSP или управление которыми осуществляется от его имени (например, посредством управления мобильными устройствами), которые ограничены короткими тайм-аутами неактивности, установленными агентством, и используют факторы активации устройства, отвечающие соответствующим требованиям этого раздела.

3.2.11. Подключённые аутентификаторы

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

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

3.2.11.1. Проводные соединения

Проводные соединения, включая соединения со встроенными аутентификаторами, МОГУТ (MAY) считаться заслуживающими доверия, поскольку их поверхность атаки минимальна. Заявителям СЛЕДУЕТ (SHOULD) рекомендовать использовать доверенное аппаратное обеспечение (например, кабели, адаптеры), чтобы удостовериться, что оно не было скомпрометировано.

3.2.11.2. Беспроводные соединения

Беспроводные соединения аутентификаторов потенциально уязвимы для угроз, включая атаки подслушивания, внедрения и ретрансляции. Беспроводные соединения включают технологии, функционирующие при отсутствии физического соединения, такие как радиочастотные (например, Bluetooth и NFC), оптические и акустические технологии.

Возможность таких атак на беспроводные соединения зависит от эффективной дальности действия технологии. Чтобы минимизировать поверхность атаки для угроз соединению аутентификатора с конечной точкой, процесс аутентификации ДОЛЖЕН (SHALL) требовать физической близости между аутентификатором и конечной точкой путём установления беспроводного соединения с дальностью действия не более 240 метров.3

Беспроводные соединения ДОЛЖНЫ (SHALL) устанавливать ключ для зашифрованного обмена данными между аутентификатором и конечной точкой одним из следующих способов:

  1. Через временное проводное соединение между устройствами.
  2. Через процесс ассоциации, похожий на процесс сопряжения, но не требующий постоянной связи между устройствами для установления ключа для зашифрованного обмена данными между аутентификатором и конечной точкой. Процесс ассоциации ДОЛЖЕН (SHALL) использовать код сопряжения4 или иной общий секрет между устройствами. Либо аутентификатор, либо конечная точка ДОЛЖНЫ (SHALL) иметь код сопряжения, который МОЖЕТ (MAY) быть напечатан на устройстве. Код сопряжения ДОЛЖЕН (SHALL) иметь длину не менее шести десятичных цифр (или эквивалент). Он ДОЛЖЕН (SHALL) передаваться между устройствами путём ручного ввода либо с использованием QR-кода или аналогичного визуально передаваемого представления.

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

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

Сетевые соединения и беспроводные технологии с эффективной дальностью действия 1 метр или более (например, Bluetooth Low Energy [BLE]) ДОЛЖНЫ (SHALL) использовать аутентифицированный защищённый канал между аутентификатором и конечной точкой. Вся транзакция аутентификации ДОЛЖНА (SHALL) быть зашифрована.

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

Примером беспроводного соединения с аутентификатором является виртуальный контактный интерфейс, определённый в [SP800-73pt2].

3.2.11.3. Гибридные соединения

Гибридные соединения используют комбинацию технологий для установления защищённого соединения между аутентификатором и конечной точкой через службу сетевого туннеля. Визуальное представление (например, QR-код) используется для поддержки установления ключа между аутентификатором и конечной точкой и дополняется беспроводной технологией (например, Bluetooth LE), чтобы требовать физической близости между сторонами при создании ассоциации. Требование физической близости аутентификатора уменьшает возможность фишинговых атак, которые в противном случае могли бы связать аутентификатор с конечной точкой атакующего.

Гибридные соединения (например, гибридные транспорты, определённые протоколом CTAP2.2 [FIDO2]) ДОЛЖНЫ (SHALL) устанавливаться между аутентификаторами и конечными точками одним из следующих способов:

  1. Посредством передачи начальной ключевой информации и идентичности используемой службы туннеля через отображаемый QR-код или аналогичное визуальное представление в сочетании с получением конечной точкой беспроводных данных, содержащих дополнительную информацию, необходимую для установления туннельного соединения. Беспроводные данные ДОЛЖНЫ (SHALL) передаваться по технологии с максимальной эффективной дальностью действия не более 240 метров.
  2. Через кэшированные ключевую и туннельную информацию, сохранённую аутентификатором и конечной точкой из предыдущей транзакции аутентификации.

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

3.2.12. Случайные значения

Случайные значения широко используются в процессах аутентификации в различных ролях (например, одноразовые числа, секреты аутентификации). Если не указано иное, случайные значения, ссылающиеся на этот раздел, ДОЛЖНЫ (SHALL) генерироваться одобренным генератором случайных битов [RBG]5, обеспечивающим как минимум минимальную криптографическую стойкость, указанную в последней редакции [SP800-131A] (то есть 112 бит по состоянию на дату этой публикации).

3.2.13. Экспортируемость

Экспортируемость — это способность аутентификатора воспроизводить, совместно использовать или хранить свои ключи аутентификации за пределами защищённой границы аутентификатора (например, копировать их в другой аутентификатор, создавать резервную копию ключа в отдельном месте хранения). В целом ключи аутентификации считаются экспортируемыми, если только аутентификатор не генерирует, не хранит и не использует ключи в защищённой аппаратной среде, предотвращающей доступ программного обеспечения к ключам, например в сопроцессоре безопасности (например, TPM) или выделенном устройстве (например, ключе безопасности). Это предназначено для предотвращения копирования или утечки секрета аутентификации программным обеспечением на конечной точке. Неэкспортируемые ключи аутентификации считаются более защищёнными; соответственно, неэкспортируемые криптографические ключи требуются при AAL3. Ключи аутентификации на синхронизируемых аутентификаторах по своей сути экспортируемы (см. приложение B).

Чтобы считаться неэкспортируемым, аутентификатор ДОЛЖЕН (SHALL) быть либо отдельным аппаратным устройством, либо встроенным процессором или средой исполнения (например, защищённым элементом, TEE, TPM). Эти аппаратные аутентификаторы и встроенные процессоры отделены от хост-процессора, такого как CPU в ноутбуке или мобильном устройстве. Неэкспортируемый аутентификатор ДОЛЖЕН (SHALL) быть спроектирован так, чтобы запрещать экспорт секрета аутентификации в хост-процессор, и НЕ ДОЛЖЕН (SHALL NOT) допускать перепрограммирование хост-процессором, позволяющее извлечь секрет. Аутентификатор подпадает под применимые требования [FIPS140]. Организациям СЛЕДУЕТ (SHOULD) применять аутентификаторы, прошедшие независимое тестирование безопасности, например аутентификаторы, валидированные на общий уровень безопасности 2 [FIPS140] с физической безопасностью уровня 36 или оценённые в соответствии с релевантными Common Criteria Protection Profiles.

3
Предел в 240 метров был выбран на основе максимальной ожидаемой дальности действия соединения Bluetooth.
4
В значении, используемом в этом разделе, термин код сопряжения не подразумевает, что обязательно используется постоянный процесс сопряжения (например, Bluetooth).
5
Подробную информацию о генерации случайных значений можно найти в [SP800-90A], [SP800-90B] и [SP800-90C].
6
В этом случае оценка FIPS 140 удовлетворяла бы минимальному требованию валидации уровня безопасности 1 [FIPS140] для аутентификаторов, закупаемых федеральными агентствами.

NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management — «Руководящие указания по цифровой идентификации: аутентификация и управление аутентификаторами»

Июль 2025 г.

4. Управление событиями аутентификатора

Этот раздел является нормативным.

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

4.1. Привязка аутентификатора

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

Аутентификаторы ДОЛЖНЫ (SHALL) быть привязаны к учётным записям подписчиков одним из следующих способов:

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

Набор руководств SP 800-63 использует термин «привязка», а не «выдача» аутентификаторов, чтобы охватить оба варианта.

На протяжении всего срока существования цифровой идентичности CSP ДОЛЖНЫ (SHALL) вести учёт всех аутентификаторов, привязанных к каждой учётной записи подписчика. CSP ДОЛЖЕН (SHALL) определить характеристики привязываемого аутентификатора (например, однофакторный или многофакторный, устойчивый к фишингу или нет), чтобы верификаторы могли оценивать соблюдение требований на каждом AAL. Такое определение МОЖЕТ (MAY) основываться на убедительных доказательствах (например, аттестации аутентификатора), непосредственной информации, полученной при выдаче аутентификатора, либо типичных характеристиках реализаций аутентификаторов (например, установлен ли бит проверки пользователя согласно [WebAuthn]).

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

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

В рамках процесса привязки CSP МОЖЕТ (MAY) потребовать дополнительную информацию о новом аутентификаторе или связанной с ним конечной точке, чтобы определить, пригоден ли он для запрошенного AAL.

4.1.1. Привязка при регистрации

Привязка во время регистрации считается частью процесса регистрации и рассматривается в [SP800-63A].

4.1.2. Привязка после регистрации
4.1.2.1. Привязка дополнительного аутентификатора

Чтобы свести к минимуму потребность в восстановлении учётной записи, CSP и верификаторам СЛЕДУЕТ (SHOULD) побуждать подписчиков поддерживать как минимум два отдельных средства аутентификации. Например, подписчик, который обычно использует OTP-аутентификатор в качестве физического аутентификатора, МОЖЕТ (MAY) также получить аутентификаторы с секретом поиска (look-up secret) либо зарегистрировать устройство для аутентификации вне полосы, которое будет использоваться в случае утраты, кражи или повреждения физического аутентификатора. Дополнительные сведения о замене паролей см. в разд. 4.2.

Соответственно, CSP ДОЛЖНЫ (SHALL) разрешать привязку нескольких аутентификаторов к учётной записи подписчика. Когда к учётной записи подписчика привязывается любой новый аутентификатор, CSP ДОЛЖЕН (SHALL) обеспечить, чтобы процесс требовал аутентификации либо на максимальном AAL, доступном в настоящее время в учётной записи подписчика, либо на максимальном AAL, на котором будет использоваться новый аутентификатор, — в зависимости от того, какой из них ниже. Например, привязка аутентификатора, пригодного для использования на AAL2, требует аутентификации на AAL2, если только учётная запись подписчика в настоящее время располагает лишь возможностями аутентификации AAL1. При добавлении аутентификатора CSP ДОЛЖЕН (SHALL) уведомить подписчика через механизм, независимый от транзакции привязки нового аутентификатора, как описано в разд. 4.6.

4.1.2.2. Привязка между конечными точками

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

Процесс привязки ДОЛЖЕН (SHALL) выполняться одним из следующих способов:

  • Конечная точка, аутентифицировавшаяся перед CSP, запрашивает у CSP код привязки. Код привязки вводится в конечную точку, связанную с новым аутентификатором, и отправляется CSP.
  • Конечная точка, связанная с новым аутентификатором, получает код привязки от CSP. Код привязки вводится в аутентифицированную конечную точку и отправляется CSP.

В дополнение к требованиям разд. 4.1.2.1 и разд. 4.2 при привязке внешнего аутентификатора ДОЛЖНЫ (SHALL) применяться следующие требования:

  • Конечная точка, связанная с новым аутентификатором, и CSP ДОЛЖНЫ (SHALL) установить аутентифицированный защищённый канал.
  • Подписчику МОЖЕТ (MAY) быть предложено ввести в конечной точке, связанной с новым аутентификатором, идентификатор, по которому CSP его знает.
  • CSP ДОЛЖЕН (SHALL) сформировать код привязки с использованием одобренного генератора случайных битов, как описано в разд. 3.2.12, и отправить его либо в конечную точку нового аутентификатора, либо в аутентифицированную конечную точку, подтверждающую привязку. Код привязки ДОЛЖЕН (SHALL) иметь длину не менее 40 бит, если он используется с идентификатором, введённым на предыдущем шаге. В противном случае ДОЛЖЕН (SHALL) требоваться код привязки длиной не менее 112 бит.
  • Подписчик ДОЛЖЕН (SHALL) передать код привязки другой конечной точке. Эта передача ДОЛЖНА (SHALL) быть либо ручной, либо осуществляться локальным методом вне полосы (например, QR-кодом). Код привязки НЕ ДОЛЖЕН (SHALL NOT) передаваться по какому-либо незащищённому каналу (например, электронной почте).
  • Код привязки ДОЛЖЕН (SHALL) быть пригоден для использования только один раз и ДОЛЖЕН (SHALL) быть действителен не более 10 минут.
  • После привязки нового аутентификатора (или выдачи сертификата в случае аутентификаторов на основе PKI) CSP СЛЕДУЕТ (SHOULD) побуждать подписчика пройти аутентификацию с новым аутентификатором, чтобы подтвердить успешное завершение процесса.
  • CSP ДОЛЖЕН (SHALL), по мере необходимости, предоставить чёткие инструкции о том, что следует сделать подписчику при сбое привязки аутентификатора (например, сделать доступной кнопку для нажатия или контактный адрес, используемый для быстрого аннулирования ошибочно привязанного аутентификатора). Это МОЖЕТ (MAY) быть предоставлено в аутентифицированном сеансе в дополнение к уведомлению о привязке, описанному в разд. 4.6.

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

4.1.3. Привязка к предоставленному подписчиком аутентификатору

Подписчик может уже владеть аутентификаторами, пригодными для аутентификации на определённом AAL. Например, у подписчика может быть собственный многофакторный аутентификатор, который он желает использовать у верификатора, требующего AAL2.

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

В рамках этого процесса CSP потребуется установить возможности и характеристики предоставленного подписчиком аутентификатора, который они желают принять, чтобы определить его пригодность для варианта использования и предполагаемого AAL. Требуемый CSP уровень уверенности в достоверности этих атрибутов аутентификатора МОЖЕТ (MAY) различаться в зависимости от варианта использования и среды угроз. Некоторые аутентификаторы, например основанные на стандарте WebAuthn [WebAuthn], предоставляют метаданные об аутентификаторе в процессе привязки или аутентификации, которые CSP может использовать при принятии своих решений. Эти метаданные, например, могут указывать, использует ли аутентификатор фактор активации для функционирования в качестве многофакторного аутентификатора. Аналогично, некоторые кошельки, контролируемые подписчиком, также будут предоставлять метаданные о своих функциях, включая сведения о механизмах, используемых для разблокирования кошелька. CSP СЛЕДУЕТ (SHOULD) учитывать эти метаданные при выборе способа поддержки предоставленного подписчиком аутентификатора.

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

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

4.1.4. Продление

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

4.2. Восстановление учётной записи

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

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

Замена забытого пароля в случае, когда подписчик может аутентифицироваться с одним или несколькими другими аутентификаторами, считается привязкой нового аутентификатора (см. разд. 4.1.2.1), а не восстановлением учётной записи.

4.2.1. Методы восстановления учётной записи

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

  • сохранённые коды восстановления;
  • выданные коды восстановления;
  • использование контактов для восстановления;
  • повторная проверка идентичности.

CSP ДОЛЖНЫ (SHALL) поддерживать один или несколько из них и МОГУТ (MAY) поддерживать метод, специфичный для приложения (например, взаимодействие с представителем CSP), для восстановления учётной записи подписчика. Использование альтернативных методов ДОЛЖНО (SHALL) основываться на анализе рисков и документироваться CSP.

4.2.1.1. Сохранённые коды восстановления

При регистрации CSP, поддерживающему этот вариант восстановления, СЛЕДУЕТ (SHOULD) выдать подписчику код восстановления. Код восстановления ДОЛЖЕН (SHALL) включать не менее 64 битов, полученных от одобренного генератора случайных битов. Сохранённый код восстановления может быть представлен в виде числа либо печатаемого представления ASCII (например, Base64) для ручного ввода, либо машиночитаемой оптической метки (например, QR-кода), содержащей код восстановления. В любой момент после регистрации подписчик МОЖЕТ (MAY) запросить заменяющий код восстановления. Выдача заменяющего кода восстановления ДОЛЖНА (SHALL) приводить к уведомлению о восстановлении учётной записи, как описано в разд. 4.6.

Руководство по цифровой идентификации

NIST SP 800-63B-4
Июль 2025
Аутентификация и управление аутентификаторами

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

4.2.1.2. Выданные коды восстановления

CSP, поддерживающие этот вариант, позволяют подписчику поддерживать один или несколько адресов восстановления (например, почтовый адрес, электронную почту, текстовое сообщение, голосовую связь). Когда требуется восстановление, код восстановления будет отправлен на адрес, выбранный заявителем. Выданный код восстановления ДОЛЖЕН (SHALL) включать не менее шести десятичных цифр (или эквивалент) от одобренного генератора случайных битов, как описано в разд. 3.2.12. Выданный код восстановления может быть представлен в виде числового или печатаемого ASCII-представления (например, Base64) для ручного ввода, защищённой ссылки (например, https), содержащей представление кода восстановления, или машиночитаемой оптической метки (например, QR-кода), содержащей код восстановления.

Выданные коды восстановления ДОЛЖНЫ (SHALL) быть действительны не более:

  • 21 дня при отправке на почтовый адрес в пределах континентальной части Соединённых Штатов;
  • 30 дней при отправке на почтовый адрес за пределами континентальной части Соединённых Штатов;
  • 10 минут при отправке посредством текстового сообщения или голосовой связи;
  • 24 часов при отправке на адрес электронной почты.

Проверка выданных кодов восстановления ДОЛЖНА (SHALL) подчиняться требованиям ограничения частоты из разд. 3.2.2.

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

4.2.1.3. Контакты для восстановления

CSP, поддерживающие использование контактов для восстановления, ДОЛЖНЫ (SHALL) позволять подписчику указать один или несколько адресов доверенных лиц для получения выданных кодов восстановления. Требования к контактам для восстановления очень похожи на требования к выданным кодам восстановления, за следующими исключениями:

  • Срок действия кодов восстановления, отправленных контактам для восстановления, МОЖЕТ (MAY) быть продлён на 24 часа (например, до не более чем 24 часов и 10 минут при отправке посредством текстового сообщения), чтобы предоставить контакту для восстановления дополнительное время для передачи кода восстановления подписчику.
  • Подтверждение адреса для кода восстановления также МОЖЕТ (MAY) быть продлено на 24 часа, чтобы позволить контакту для восстановления отправить подписчику код подтверждения для ввода.

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

4.2.1.4. Повторное подтверждение личности

Если учётная запись подписчика прошла подтверждение личности как минимум на уровне обеспечения идентификации 1 (IAL1), CSP СЛЕДУЕТ (SHOULD) поддерживать восстановление учётной записи путём повторения части процесса подтверждения личности. CSP ДОЛЖЕН (SHALL) повторить необходимые этапы подтверждения личности в соответствии с уровнем первоначального подтверждения личности и ДОЛЖЕН (SHALL) подтвердить, что личность заявителя соответствует ранее установленной учётной записи. Если CSP сохранил биометрический образец пользователя или копию свидетельства, использованного при первоначальном подтверждении личности, достаточного качества и разрешения, CSP МОЖЕТ (MAY) повторить только часть процесса подтверждения личности, относящуюся к проверке, как описано в [SP800-63A].

4.2.2. Требования к восстановлению по IAL/AAL

Применяются разные методы восстановления в зависимости от IAL и максимального AAL, связанных с учётной записью подписчика.

4.2.2.1. Восстановление без подтверждения личности

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

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

4.2.2.2. Восстановление при AAL2

Чтобы восстановить учётную запись, которая может аутентифицироваться максимум на AAL2, CSP ДОЛЖЕН (SHALL) потребовать от подписчика выполнить одно из следующего:

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

Если учётная запись, которая может аутентифицироваться при AAL3, прошла подтверждение личности при IAL1 или IAL2, требования совпадают с требованиями для восстановления при AAL2.

Если учётная запись, которая может аутентифицироваться при AAL3, прошла подтверждение личности при IAL3, CSP ДОЛЖЕН (SHALL) успешно выполнить успешное биометрическое сравнение с биометрической характеристикой, собранной во время первоначального очного сеанса подтверждения личности под наблюдением, как описано в [SP800-63A]. CSP МОЖЕТ (MAY) также потребовать предъявления свидетельства, использованного в первоначальном процессе подтверждения личности.

4.2.3. Уведомление о восстановлении учётной записи

Во всех случаях восстановление учётной записи ДОЛЖНО (SHALL) приводить к отправке уведомления подписчику или назначенному им лицу, как описано в разд. 4.6.

4.3. Утрата, кража, повреждение и компрометация

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

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

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

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

4.4. Истечение срока действия

CSP МОГУТ (MAY) привязывать к учётным записям подписчиков аутентификаторы, срок действия которых истекает. Когда срок действия аутентификатора истекает, он НЕ ДОЛЖЕН (SHALL NOT) быть пригоден для аутентификации. Когда предпринимается попытка аутентификации с использованием аутентификатора с истекшим сроком действия, CSP СЛЕДУЕТ (SHOULD) указать подписчику, что сбой аутентификации обусловлен истечением срока действия, а не иной причиной.

CSP СЛЕДУЕТ (SHOULD) изъять любой аутентификатор, содержащий персональную информацию, либо обеспечить его стирание или уничтожение незамедлительно после истечения срока действия.

Замена аутентификаторов с истекшим сроком действия ДОЛЖНА (SHALL) соответствовать процессу привязки дополнительного аутентификатора, как описано в разд. 4.1.2.

4.5. Аннулирование

Аннулирование аутентификатора (иногда называемое отзывом или прекращением действия) представляет собой удаление привязки между аутентификатором и учётной записью подписчика.

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

CSP СЛЕДУЕТ (SHOULD) изъять любой аутентификатор, содержащий персональную информацию, либо обеспечить его стирание или уничтожение незамедлительно после аннулирования. CSP СЛЕДУЕТ (SHOULD) уведомить подписчика, когда аутентификатор аннулирован, как описано в разд. 4.6.

Дополнительные требования к аннулированию аутентификаторов PIV приведены в [FIPS201].

4.6. Уведомления об учётной записи

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

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

  • почтовый адрес;
  • адрес электронной почты;
  • адрес (например, номер телефона), на который может быть отправлено текстовое или голосовое сообщение;
  • ссылка на подписчика в службе push-уведомлений.

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

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

Уведомление ДОЛЖНО (SHALL) содержать ясные инструкции, включая контактную информацию, на случай, если получатель отрицает событие, связанное с уведомлением.

Digital Identity Guidelines: Authentication and Authenticator Management

NIST SP 800-63B-4
Июль 2025

5. Управление сеансами

Этот раздел является нормативным.

После наступления события аутентификации часто желательно позволить подписчику продолжать пользоваться приложением в ходе нескольких последующих взаимодействий, не требуя от него повторять событие аутентификации. Это особенно характерно для сценариев федерации (см. [SP800-63C]), в которых событие аутентификации неизбежно предполагает координацию нескольких компонентов и сторон через сеть.

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

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

5.1. Привязки сеанса

Сеанс возникает между программным обеспечением (то есть субъектом сеанса), которое использует подписчик (например, браузером, приложением, операционной системой), и RP или CSP, к которым обращается подписчик (то есть хостом сеанса). Секрет сеанса ДОЛЖЕН (SHALL) совместно использоваться программным обеспечением подписчика и доступной службой. Этот секрет связывает два конца сеанса и позволяет подписчику продолжать пользоваться службой с течением времени. Секрет ДОЛЖЕН (SHALL) непосредственно предъявляться программным обеспечением подписчика либо владение секретом ДОЛЖНО (SHALL) быть доказано с использованием криптографического механизма.

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

  • сеанс веб-браузера с cookie «session»;
  • экземпляр мобильного приложения, сохраняющий секрет сеанса.

Секреты сеанса, используемые в качестве токенов на предъявителя для управления сеансами, НЕ СЛЕДУЕТ (SHOULD NOT) делать постоянными (то есть сохраняемыми при перезапуске связанного приложения или перезагрузке хост-устройства), поскольку они привязаны к конкретным сеансам, которые были бы завершены перезапуском или перезагрузкой. Cookie и аналогичные возможности «remember my browser» НЕ ДОЛЖНЫ (SHALL NOT) использоваться вместо аутентификации, кроме случая, предусмотренного для повторной аутентификации на AAL2 в разд. 2.2.3, когда предел неактивности превышен, но предел времени — нет.

Некоторые технологии (например, развивающаяся спецификация учётных данных сеанса, привязанных к устройству [DBSC]) уменьшают риск кражи секретов сеанса, используя криптографические протоколы, доказывающие владение секретом сеанса, вместо использования их в качестве токенов на предъявителя. Эти технологии могут дополнительно хранить и использовать такие секреты сеанса в защищённых хранилищах ключей, чтобы снизить риск их эксфильтрации вредоносным ПО. Секреты сеанса, используемые с такими методами доказательства владения, МОГУТ (MAY) сохраняться. Однако RP и CSP ДОЛЖНЫ (SHALL) обеспечивать соблюдение пределов времени жизни сеанса, описанных в разд. 2.2.3, даже когда продемонстрировано знание секрета сеанса.

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

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

  1. Секреты устанавливаются во время аутентификации или непосредственно после неё.
  2. Секреты устанавливаются с использованием входных данных от одобренного генератора случайных битов, как описано в разд. 3.2.12, и имеют длину не менее 64 бит.
  3. Секреты стираются или аннулируются субъектом сеанса, когда подписчик выходит из системы.
  4. Секреты либо передаются от хоста сеанса к RP или CSP через аутентифицированный защищённый канал, либо выводятся из ключей, которые устанавливаются в рамках установления действительного взаимно аутентифицированного защищённого канала.
  5. Срок действия секретов истекает, и они не принимаются после моментов времени, указанных в разд. 2.1.3, разд. 2.2.3 и разд. 2.3.3, в зависимости от AAL.
  6. Секреты недоступны посредникам между хостом и конечной точкой подписчика.

Кроме того, секреты, используемые для привязки сеанса, СЛЕДУЕТ (SHOULD) стирать на конечной точке подписчика, когда он выходит из системы или когда секрет считается истёкшим. Их НЕ СЛЕДУЕТ (SHOULD NOT) размещать в небезопасных местах (например, в HTML5 Local Storage) из-за потенциальной подверженности локального хранилища атакам межсайтового выполнения сценариев (XSS).

После аутентификации аутентифицированные сеансы НЕ ДОЛЖНЫ (SHALL NOT) переключаться на небезопасный транспорт (например, с https на http).

Содержимое POST/PUT ДОЛЖНО (SHALL) содержать идентификатор сеанса, который RP ДОЛЖНА (SHALL) проверять для защиты от межсайтовой подделки запросов (CSRF).

Для управления сеансом с течением времени существует несколько механизмов. В следующих разделах приведены различные примеры, дополнительные требования и соображения для каждой технологии-примера. Дополнительные информационные указания доступны в памятке Open Worldwide Application Security Project (OWASP) Session Management Cheat Sheet [OWASP-session].

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

5.1.1. Cookie браузера

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

Cookie, используемые для поддержания сеанса:

  1. ДОЛЖНЫ (SHALL) быть помечены как доступные только в защищённых (то есть HTTPS) сеансах.
  2. ДОЛЖНЫ (SHALL) быть доступны для минимально практически необходимых имён хостов и путей.
  3. СЛЕДУЕТ (SHOULD) помечать как недоступные через JavaScript (то есть HttpOnly).
  4. СЛЕДУЕТ (SHOULD) помечать как истекающие в момент окончания или вскоре после окончания периода действия сеанса. Это требование предназначено для ограничения накопления cookie, но НЕ ДОЛЖНО (SHALL NOT) использоваться для обеспечения тайм-аутов сеанса.
  5. СЛЕДУЕТ (SHOULD) иметь префикс «__Host-» и устанавливать «Path=/».
  6. СЛЕДУЕТ (SHOULD) устанавливать «SameSite=Lax» или «SameSite=Strict».
  7. СЛЕДУЕТ (SHOULD) содержать только непрозрачную строку (например, идентификатор сеанса) и НЕ ДОЛЖНЫ (SHALL NOT) содержать персональную информацию в открытом виде.
5.1.2. Токены доступа

Токен доступа (например, OAuth [RFC6749]) используется, чтобы позволить приложению после события аутентификации получать доступ к набору служб от имени подписчика. RP НЕ ДОЛЖНА (SHALL NOT) интерпретировать наличие токена доступа как показатель присутствия подписчика при отсутствии других сигналов. Токен доступа и любые связанные с ним токены обновления могут оставаться действительными ещё долго после окончания сеанса аутентификации и выхода подписчика из приложения.

5.2. Повторная аутентификация

Периодическая повторная аутентификация сеансов ДОЛЖНА (SHALL) выполняться для подтверждения продолжающегося присутствия подписчика в аутентифицированном сеансе (например, того, что подписчик не отошёл, не выйдя из системы).

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

Пределы истечения общего тайм-аута и тайм-аута неактивности зависят от нескольких факторов, включая AAL сеанса, среду, в которой проводится сеанс (например, находится ли подписчик в зоне ограниченного доступа), тип используемой конечной точки (например, мобильное приложение, веб-приложение), является ли конечная точка управляемым устройством,7 и характер самого приложения. Пределы также МОГУТ (MAY) быть продлены при использовании технологий поддержания сеанса с более высоким уровнем безопасности (например, механизмов, привязанных к устройству). Агентства ДОЛЖНЫ (SHALL) устанавливать и документировать применяемые пределы времени неактивности и общего времени в плане обеспечения безопасности системы, таком как описанный в [SP800-39]. Подробные требования для каждого AAL приведены в разд. 2.1.3, разд. 2.2.3 и разд. 2.3.3.

Особые соображения применяются к управлению сеансами и повторной аутентификации при использовании протокола федерации и IdP для аутентификации в RP, как описано в [SP800-63C]. Протокол федерации передаёт событие аутентификации в IdP в RP с использованием утверждения, а затем RP начинает аутентифицированный сеанс на основе успешной проверки этого утверждения. Поскольку IdP и RP управляют сеансами отдельно друг от друга, а протокол федерации не связывает управление сеансами между IdP и RP, завершение сеансов подписчика в IdP и RP не зависит друг от друга. Аналогично, сеансы подписчика в нескольких разных RP устанавливаются и завершаются независимо друг от друга.

Следовательно, когда сеанс RP истекает и RP требует повторной аутентификации, возможно, что сеанс в IdP ещё не истёк и что новое утверждение может быть сформировано из этого сеанса в IdP без явной повторной аутентификации подписчика. IdP может передавать RP время и детали события аутентификации, но RP ДОЛЖНА (SHALL) быть полномочным источником при определении того, выполнены ли требования повторной аутентификации. Раздел 4.7 [SP800-63C] предоставляет дополнительные сведения и требования по управлению сеансами в контексте федерации.

5.3. Мониторинг сеанса

Мониторинг сеанса (иногда называемый непрерывной аутентификацией) представляет собой непрерывную оценку характеристик сеанса для обнаружения возможного мошенничества во время сеанса. Мониторинг сеанса МОЖЕТ (MAY) выполняться RP совместно с CSP или IdP и связанным верификатором как мера снижения риска. Когда во время сеанса выявлено потенциальное мошенничество, RP СЛЕДУЕТ (SHOULD) действовать совместно с CSP, IdP или верификатором, чтобы повторно аутентифицировать, завершить сеанс либо уведомить соответствующий персонал поддержки. Характеристики сеанса, которые МОГУТ (MAY) оцениваться, включают:

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

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

Мониторинг сеанса МОЖЕТ (MAY) быть облегчён использованием совместной сигнализации между RP и CSP или IdP, как описано в [SP800-63C].

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

NIST SP 800-63B-4

Digital Identity Guidelines

Июль 2025

Authentication and Authenticator Management

6. Угрозы и соображения безопасности

Этот раздел носит информационный характер.

6.1. Угрозы для аутентификаторов

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

  • «То, что вы знаете», может быть раскрыто злоумышленнику. Например, злоумышленник может угадать пароль. Если аутентификатор представляет собой общий секрет, злоумышленник может получить доступ к CSP или верификатору и получить секретное значение либо выполнить словарную атаку на хеш этого значения. Злоумышленник может наблюдать ввод PIN-кода или пароля, найти письменную запись либо запись в журнале PIN-кода или пароля или установить вредоносное ПО (например, кейлоггер), чтобы перехватить секрет. Кроме того, злоумышленник может определить секрет посредством офлайн-атак на базу данных паролей, поддерживаемую верификатором.
  • «То, чем вы владеете», может быть утрачено, повреждено, украдено у владельца или скопировано злоумышленником. Например, злоумышленник, получивший доступ к компьютеру владельца, может скопировать программный аутентификатор. Аппаратный аутентификатор может быть украден, подвергнут вмешательству или продублирован. Секреты, передаваемые по отдельному каналу, могут быть перехвачены злоумышленником и использованы для аутентификации его собственного сеанса. Подписчика могут методами социальной инженерии склонить предоставить доступ к секретам без намеренного сговора.
  • «То, чем вы являетесь», может быть воспроизведено либо возможно ложное совпадение. Например, злоумышленник может получить копию отпечатка пальца подписчика и создать реплику.

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

Таблица 3. Угрозы для аутентификаторов
Угроза/атака на аутентификаторОписаниеПримеры
КражаЗлоумышленник крадет физический аутентификатор.Украден аппаратный криптографический аутентификатор.
Украден OTP-аутентификатор.
Украден аутентификатор с секретом из таблицы поиска.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторОписаниеПримеры
Украден мобильный телефон.
ДублированиеАутентификатор подписчика был скопирован с его ведома или без него.Раскрыты пароли, записанные на бумаге.
Скопированы пароли, хранящиеся в электронном файле.
Эксплуатирована уязвимость недостаточно защищенного менеджера паролей.
Скопирован программный PKI-аутентификатор (то есть закрытый ключ).
Скопирован аутентификатор с секретом из таблицы поиска.
Изготовлен поддельный биометрический аутентификатор.
Экспортируемые криптографические ключи получены с устройства или из облачной среды синхронизации.
ПрослушиваниеЗлоумышленник наблюдает секрет аутентификатора или вывод аутентификатора во время аутентификации подписчика.Пароли получены путем наблюдения за вводом с клавиатуры.
Пароли или выводы аутентификатора перехвачены программой регистрации нажатий клавиш.
PIN-код перехвачен с устройства ввода PIN-кода.
Хешированный пароль получен и использован злоумышленником для другой аутентификации.
Злоумышленник перехватывает секрет, передаваемый по отдельному каналу, скомпрометировав канал связи.Секрет, передаваемый по отдельному каналу, передан по незашифрованному Wi-Fi и получен злоумышленником.
Офлайн-взломАутентификатор раскрывается с использованием аналитических методов вне механизма аутентификации.Программный PKI-аутентификатор подвергается словарной атаке для определения правильного пароля, необходимого для расшифрования закрытого ключа.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторОписаниеПримеры
Атака по побочному каналуСекрет аутентификатора раскрывается с использованием физических характеристик аутентификатора.Ключ извлекается посредством дифференциального анализа энергопотребления аппаратного криптографического аутентификатора.
Секрет криптографического аутентификатора извлекается путем анализа времени ответа аутентификатора в ходе нескольких попыток.
Фишинг или фармингВывод аутентификатора перехватывается посредством введения заявителя в заблуждение, чтобы он считал злоумышленника верификатором или RP.Заявитель раскрывает пароль веб-сайту, выдающему себя за верификатор.
Подписчик банка раскрывает пароль в ответ на запрос, полученный по электронной почте, от фишера, выдающего себя за представителя банка.
Заявитель раскрывает пароль на поддельном веб-сайте верификатора, на который он попал вследствие DNS-спуфинга.
Социальная инженерияЗлоумышленник устанавливает с подписчиком уровень доверия, чтобы убедить его раскрыть секрет аутентификатора или вывод аутентификатора.Подписчик раскрывает пароль коллеге, запрашивающему пароль от имени начальника подписчика.
Подписчик раскрывает пароль в ходе телефонного запроса от злоумышленника, выдающего себя за системного администратора.
Злоумышленник, убедивший мобильного оператора перенаправить ему мобильный телефон жертвы, получает секрет, передаваемый по отдельному каналу посредством SMS.
Усталость от аутентификацииЗлоумышленник вызывает отправку подписчику повторяющихся запросов аутентификации в попытке заставить его их одобрить.Подписчик одобряет мошеннический запрос push-аутентификации, чтобы прекратить повторяющиеся запросы.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторОписаниеПримеры
Онлайн-угадываниеЗлоумышленник подключается к верификатору в режиме онлайн и пытается угадать действительный вывод аутентификатора в контексте этого верификатора.Для угадывания паролей используются онлайн-словарные атаки.
Онлайн-угадывание используется для угадывания выводов OTP-аутентификатора, зарегистрированного у легитимного подписчика.
Компрометация оконечной точкиПрокси вредоносного кода на оконечной точке обеспечивает удаленный доступ к подключенному аутентификатору без согласия подписчика.Криптографический аутентификатор, подключенный к оконечной точке, используется для аутентификации удаленных злоумышленников.
Вредоносный код на оконечной точке вызывает аутентификацию перед верификатором, отличным от предполагаемого.Аутентификация выполняется от имени злоумышленника, а не подписчика.
Вредоносное приложение на оконечной точке считывает секрет, передаваемый посредством SMS по отдельному каналу, и злоумышленник использует этот секрет для аутентификации.
Вредоносный код на оконечной точке компрометирует многофакторный программный криптографический аутентификатор.Прокси вредоносного кода выполняют аутентификацию или экспортируют ключи аутентификатора с оконечной точки.
Несанкционированная привязкаЗлоумышленник вызывает привязку находящегося под его контролем аутентификатора к учетной записи подписчика.Злоумышленник перехватывает аутентификатор или ключ подготовки на пути к подписчику.
Сохранившиеся ключиВыведенное из эксплуатации устройство сохраняет ключи аутентификации.Устройство (например, портативный компьютер) продается без осознания того, что ключи аутентификации на основе устройства присутствуют и могут быть использованы новым владельцем.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторОписаниеПримеры
Распространение ключейПередача ключей аутентификации на основе устройства между устройствами увеличивает поверхность атаки.Подписчик копирует ключи аутентификации на множество устройств, возможно, часть из которых не находится под его непосредственным контролем, и теряет представление о том, где хранятся ключи.
Безопасность передачи ключейКлючи аутентификации передаются между устройствами через недостаточно защищенный облачный сервис.Доступ к облачному сервису, хранящему ключи аутентификации, требует только однофакторной аутентификации.
Ключи становятся доступными другим лицам по URL, отправленному по электронной почте.
Недоверенные устройстваКлючи аутентификации размещены на устройстве, обеспечивающем недостаточную защиту.Ключи передаются на небезопасное устройство через среду синхронизации.
Внутренние угрозыДоверенное внутреннее лицо оказывается недостойным доверия.Внутреннее лицо, имеющее доступ к CSP (например, представитель службы поддержки), вступает в сговор со злоумышленником, чтобы предоставить доступ к учетным записям подписчиков.

6.2. Стратегии смягчения угроз

В таблице 4 приведены связанные механизмы, содействующие смягчению угроз, описанных в таблице 3.

Таблица 4. Смягчение угроз для аутентификаторов
Угроза/атака на аутентификаторМеханизмы смягчения угрозНормативные справочные разделы
КражаИспользуйте многофакторные аутентификаторы, которые должны активироваться посредством пароля или биометрического признака.2.2.1, 2.3.1
Используйте сочетание аутентификаторов, включающее пароль или биометрический признак.2.2.1, 2.3.1

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторМеханизмы смягчения угрозНормативные справочные разделы
ДублированиеИспользуйте аутентификаторы, из которых сложно извлечь и продублировать долгосрочные секреты аутентификации.2.2.2, 2.3.2, 3.1.6.1
Обеспечивайте соблюдение требований AAL2 для доступа к средам синхронизации, содержащим экспортированные ключи аутентификации, и разрешайте импортировать их только на доверенные устройства.3.1.7.1
ПрослушиваниеДо использования обеспечивайте безопасность оконечной точки, особенно в отношении отсутствия вредоносного ПО (например, кейлоггеров).2.2.2
Избегайте использования неаутентифицированных и незашифрованных каналов связи для передачи секретов аутентификатора по отдельному каналу.3.1.3.1
Выполняйте аутентификацию по аутентифицированным защищенным каналам (например, обращайте внимание на значок замка в окне браузера).2.1.2, 2.2.2, 2.3.2
Используйте протоколы аутентификации, устойчивые к атакам повторного воспроизведения (например, pass-the-hash).3.2.7
Используйте конечные точки аутентификации, применяющие доверенные возможности ввода и отображения.3.1.6.1, 3.1.7.1
Офлайн-взломИспользуйте аутентификатор с секретом аутентификатора высокой энтропии.3.1.2.1, 3.1.4.1, 3.1.5.1, 3.1.6.1, 3.1.7.1
Храните централизованно проверяемые пароли в форме с солью и хешированием, включая хеш с ключом.3.1.1.1.2
Атака по побочному каналуИспользуйте алгоритмы аутентификаторов, поддерживающие постоянное энергопотребление и время выполнения независимо от значений секретов.2.3.2
Фишинг или фармингИспользуйте аутентификаторы, обеспечивающие устойчивость к фишингу.3.2.5

Продолжение на следующей странице

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

Продолжение с предыдущей страницы

Угроза/атака на аутентификаторМеханизмы снижения угрозНормативные справочные разделы
Социальная инженерияИзбегайте использования аутентификаторов, создающих риск социальной инженерии для третьих лиц (например, сотрудников службы поддержки клиентов).4.1.2.1, 4.2
Усталость от аутентификацииТребуйте передачи секрета аутентификации для OOB-аутентификации вместо одобрения.3.1.3
Подбор по сетиИспользуйте аутентификаторы, генерирующие вывод с высокой энтропией.3.1.2.1, 3.1.6.1, 3.1.7.1
Используйте аутентификатор, блокирующийся после повторяющихся неудачных попыток активации.3.2.2
Компрометация конечной точкиИспользуйте аппаратные аутентификаторы, требующие физического действия со стороны заявителя.3.2.8
Храните программные ключи в хранилище с ограниченным доступом.3.1.3.1, 3.1.6.1, 3.1.7.1, 3.2.13
Несанкционированная привязкаПредоставляйте аутентификаторы и связанные с ними ключи через аутентифицированные защищённые каналы либо лично.4.1
Скрытые ключиОбеспечьте безопасную утилизацию оборудования, содержащего ключи аутентификации, основанные на устройстве.4.4, 4.5
В федеральных корпоративных приложениях ограничивайте передачу ключей устройствам, находящимся под управлением организации или доверенным.B.2
Безопасность передачи ключейПоощряйте или требуйте от подписчиков использовать облачные сервисы, одобренные для хранения и передачи ключей.B.2

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

  • Несколько факторов затрудняют успешное осуществление атак. Если злоумышленнику необходимо похитить криптографический аутентификатор и угадать пароль, объём работы, необходимый для обнаружения обоих факторов, может оказаться слишком большим.

64

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

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

6.3. Восстановление аутентификатора

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

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

6.4. Атаки на сеансы

Атаки перехвата сеанса после события аутентификации могут иметь сходные последствия для безопасности. Руководящие указания по управлению сеансами в разделе 5 существенны для поддержания целостности сеанса при атаках (например, XSS). Также важно очищать всю отображаемую информацию [OWASP-XSS-prevention], чтобы гарантировать отсутствие в ней исполняемого содержимого. Эти руководящие указания рекомендуют сделать секреты сеанса недоступными для мобильного кода, чтобы обеспечить дополнительную защиту от эксфильтрации секретов сеанса.

Ещё одной угрозой после аутентификации является CSRF, использующая склонность пользователей одновременно поддерживать несколько активных сеансов. Крайне важно встраивать и проверять идентификатор сеанса для веб-запросов, чтобы предотвратить непреднамеренную или злонамеренную активацию действительного URL или запроса.

65

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

7. Соображения о конфиденциальности

Этот раздел носит информационный характер.

7.1. Оценка рисков для конфиденциальности

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

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

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

7.2. Средства контроля конфиденциальности

Раздел 2.4.3 требует, чтобы CSP применяли надлежащим образом адаптированные средства контроля конфиденциальности. [SP800-53] содержит набор средств контроля конфиденциальности для рассмотрения CSP при развёртывании механизмов аутентификации, включая уведомления, восстановление нарушенных прав (redress) и другие важные соображения для успешных и заслуживающих доверия развёртываний.

7.3. Ограничение использования

Раздел 2.4.3 требует, чтобы CSP поддерживали цели предсказуемости (то есть обеспечивали возможность лицам, владельцам и операторам делать надёжные предположения о персональной информации и её обработке информационной системой) и управляемости (обеспечивали возможность детального администрирования персональной информации, включая изменение, удаление и выборочное раскрытие), соразмерные рискам для конфиденциальности, которые могут возникать при обработке атрибутов для целей, отличных от установления личности, аутентификации, авторизации, утверждения атрибутов либо связанного с ними снижения мошенничества или соблюдения законов либо юридических процедур [NISTIR8062].

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

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

66

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

7.4. Соблюдение требований конфиденциальности, специфичных для агентства

Раздел 2.4.3 описывает конкретные обязательства по соблюдению требований для федеральных CSP. Критически важно привлекать SAOP на самых ранних стадиях разработки системы цифровой аутентификации для оценки и снижения рисков для конфиденциальности, а также консультирования агентства по требованиям соблюдения, например о том, приводит ли сбор персональной информации для выдачи или обслуживания аутентификаторов к применению Privacy Act of 1974 [PrivacyAct] либо возникает ли согласно E-Government Act of 2002 [E-Gov] требование провести PIA. Например, в отношении централизованного хранения биометрических данных требования Privacy Act, вероятно, будут применяться и потребуют охвата новым или существующим Privacy Act SORN вследствие сбора и хранения персональной информации и любых других атрибутов, необходимых для аутентификации. SAOP аналогичным образом может помочь агентству определить, требуется ли PIA. Эти соображения не следует истолковывать как требование разработать Privacy Act SORN или PIA только для аутентификации. Во многих случаях PIA и SORN могут охватывать весь процесс цифровой идентификации либо включать процесс цифровой аутентификации как часть более крупного программного PIA, в котором рассматриваются создаваемые агентством онлайн-услуги или льготы.

Ввиду множества компонентов цифровой аутентификации SAOP необходимо знать и понимать каждый компонент. Например, к агентству, предлагающему или использующему федеративные услуги CSP или RP, могут применяться иные документы по конфиденциальности (например, Data Use Agreements, Computer Matching Agreements). SAOP может помочь агентству определить, какие дополнительные требования применяются. Кроме того, глубокое понимание отдельных компонентов цифровой аутентификации позволит SAOP оценивать и снижать риски для конфиденциальности посредством процессов соблюдения требований или иных средств.

67

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

8. Соображения об опыте клиентов

Этот раздел носит информационный характер.

Для согласования со стандартной терминологией человеко-ориентированного проектирования, опыта клиентов и удобства использования термин «пользователь» применяется в этом разделе для обозначения человека. В большинстве случаев рассматриваемый пользователь будет субъектом в роли заявителя, заявляющего лица или подписчика. Опыт клиента находится на пересечении удобства использования, доступности и возможности выбора. Учёт потребностей пользователей позволяет организациям предоставлять отзывчивые и безопасные решения по идентификации, сводя к минимуму излишние затруднения и неудовлетворённость.

8.1. Удобство использования

[ISO/IEC9241-11] определяет удобство использования как «степень, в которой система, продукт или услуга могут использоваться указанными пользователями для достижения указанных целей с результативностью, эффективностью и удовлетворённостью в указанном контексте использования». Это определение сосредоточено на пользователях, их целях и контекстах использования как ключевых элементах, необходимых для достижения результативности, эффективности, удовлетворённости и удобства использования.

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

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

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

Использование федерации для аутентификации может смягчить многие проблемы удобства использования, хотя такой подход имеет свои компромиссы, как обсуждается в [SP800-63C].

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

68

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

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

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

Раздел 508 Закона о реабилитации 1973 года [Section508] был принят для устранения барьеров в информационных технологиях и для того, чтобы требовать от федеральных ведомств обеспечивать доступность электронной и информационной технологии для людей с инвалидностью. Хотя эти руководящие принципы непосредственно не устанавливают требования раздела 508, поставщики услуг идентификации, как ожидается, соблюдают положения раздела 508. Помимо соблюдения раздела 508, от федеральных ведомств и их поставщиков услуг обычно ожидается, что они будут проектировать услуги и системы с учетом опыта людей с инвалидностью, чтобы доступность оставалась приоритетом на протяжении всего жизненного цикла систем идентификации.

8.1.1. Общие соображения удобства использования аутентификаторов

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

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

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

К соображениям удобства использования, применимым к большинству аутентификаторов, относятся следующие:

69

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

  • Предоставляйте информацию об использовании и обслуживании аутентификатора (например, о том, что делать при его утрате или краже), а также инструкции по использованию, особенно если для первого использования или инициализации установлены различные требования.
  • Пользователям необходимо помнить, что аутентификатор должен быть у них под рукой. Рассмотрите необходимость альтернативных вариантов аутентификации для защиты от утраты, повреждения или иных негативных воздействий на исходный аутентификатор и, если применимо, от возможной разрядки батареи.
  • Альтернативные варианты аутентификации, основанные на требованиях AAL, позволяют пользователям выбирать аутентификатор с учетом их контекста, целей и задач (например, частоты и срочности задачи). Альтернативные варианты аутентификации также помогают решать проблемы доступности, которые могут возникать с конкретным аутентификатором.
  • Учитывайте характеристики текста, предназначенного для пользователя:
    • Пишите предназначенный для пользователя текст (например, инструкции, запросы, уведомления, сообщения об ошибках) простым языком для целевой аудитории. Избегайте технического жаргона и пишите с учетом ожидаемого уровня грамотности аудитории.
    • Учитывайте разборчивость текста, предназначенного для пользователя и вводимого пользователем, включая стиль, размер и цвет шрифта, а также контраст с окружающим фоном. Неразборчивый текст способствует ошибкам пользовательского ввода. Для повышения разборчивости рассмотрите использование:
      • высокого контраста (то есть черного на белом);
      • шрифтов без засечек для электронных дисплеев и шрифтов с засечками для печатных материалов;
      • шрифтов, четко различающих легко путаемые символы (например, прописную букву «O» и цифру ноль «0»);
      • минимального размера шрифта 12 пунктов, если текст помещается на экране устройства.
    • Избегайте использования значков (например, замков или щитов), которые можно спутать с индикаторами безопасности в браузерах.
  • Учитывайте пользовательский опыт при вводе аутентификатора:
    • Предоставляйте возможность отображать текст при вводе, поскольку маскированный ввод текста подвержен ошибкам. После того как данный символ отображался достаточно долго, чтобы пользователь мог его увидеть, его можно скрыть. При определении времени задержки маскирования учитывайте устройство, поскольку ввод паролей на мобильных устройствах (например, планшетах и смартфонах) занимает больше времени, чем на традиционных настольных компьютерах. Обеспечьте, чтобы продолжительность задержки маскирования соответствовала потребностям пользователей.
    • Обеспечьте достаточность времени, отведенного на ввод текста (то есть экран ввода не должен завершаться по тайм-ауту преждевременно). Обеспечьте, чтобы допустимое время ввода текста соответствовало потребностям пользователей.

70

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

    • Предоставляйте ясную, содержательную и позволяющую предпринять действие обратную связь об ошибках ввода, чтобы уменьшить замешательство и разочарование пользователей. Значительные последствия для удобства использования возникают, когда пользователи не могут узнать, что они ввели текст неправильно.
    • Разрешайте не менее 10 попыток ввода для аутентификаторов, требующих от пользователя ввести вывод аутентификатора. Чем длиннее и сложнее вводимый текст, тем выше вероятность ошибок пользовательского ввода.
    • Предоставляйте ясную и содержательную обратную связь о числе оставшихся разрешенных попыток. При ограничении частоты (то есть регулировании потока) сообщайте пользователям, сколько им придется ждать до следующей попытки.
  • Минимизируйте влияние ограничений форм-фактора, таких как ограниченные области касания и отображения на мобильных устройствах:
    • Бо́льшие области касания повышают удобство использования при вводе текста, поскольку набор на небольших устройствах значительно более подвержен ошибкам и занимает больше времени, чем набор на полноразмерной клавиатуре, вследствие размера механизма ввода (например, пальца) относительно размера экранной цели.
    • Следуйте надлежащим принципам проектирования пользовательского интерфейса и представления информации для малых дисплеев.

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

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

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

8.1.2. Соображения удобства использования по типам аутентификаторов

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

71

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

8.1.2.1. Пароли
Обычное использование

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

К соображениям удобства использования при обычном использовании без менеджера паролей относятся:

  • Запоминаемость пароля
    • Вероятность неудачи припоминания возрастает, если пользователю необходимо запомнить больше элементов. При меньшем количестве паролей пользователи могут легче вспомнить конкретный пароль, необходимый для определенной RP.
    • Нагрузка на память больше для пароля, используемого реже.

К соображениям удобства использования при обычном использовании с менеджером паролей относятся:

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

К соображениям удобства использования для прерывистых событий относятся:

  • Когда пользователи создают и изменяют пароли
    • Ясно сообщайте информацию о том, как создавать и изменять пароли.
    • Ясно сообщайте требования к паролям, указанные в разд. 3.1.1.
    • Разрешайте длину не менее 64 символов для поддержки использования парольных фраз. Поощряйте пользователей делать пароли настолько длинными, насколько они хотят, и использовать любые символы, которые им нравятся (включая пробелы), для облегчения запоминания. Обеспечьте, чтобы пользовательские интерфейсы поддерживали достаточную длину паролей.
    • Не устанавливайте для паролей другие правила состава (например, сочетания различных типов символов).

72

NIST SP 800-63B-4
Digital Identity Guidelines
Июль 2025
Authentication and Authenticator Management

    • Не требуйте произвольной (например, периодической) смены паролей, если только нет запроса пользователя или свидетельств компрометации аутентификатора (см. разд. 3.1.1).
  • Предоставляйте ясную, содержательную и позволяющую предпринять действие обратную связь, когда выбранные пароли отклоняются (например, когда пароль присутствует в «блок-листе» неприемлемых паролей или использовался ранее).
8.1.2.2. Секреты для поиска
Обычное использование

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

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

  • Пользовательский опыт при вводе секретов для поиска
    • Учитывайте сложность и размер запросов. Более крупные подмножества секретов, которые пользователю предлагается найти, имеют более существенные последствия для удобства использования. Следует учитывать как когнитивную нагрузку, так и физическую сложность ввода.
8.1.2.3. Внеполосная аутентификация
Обычное использование

Внеполосная аутентификация требует, чтобы пользователи имели доступ к основному и вторичному каналу связи.

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

  • Уведомляйте пользователей о получении секрета на устройстве, которое можно заблокировать. Если внеполосное устройство заблокировано, для доступа к секрету следует требовать аутентификацию на устройстве.
  • В зависимости от реализации учитывайте ограничения форм-фактора, которые особенно проблематичны, когда пользователи должны вводить текст на мобильных устройствах. Предоставление более крупных областей касания улучшит удобство использования при вводе секретов на мобильных устройствах.
  • Рассмотрите возможность предлагать функции, не требующие ввода текста на мобильных устройствах (например, функцию копирования и вставки), которые особенно полезны, когда основной и вторичный каналы находятся на одном устройстве. Например, пользователям трудно вручную передать секрет аутентификации с помощью смартфона, поскольку им приходится переключаться туда и обратно — возможно, многократно — между внеполосным приложением и основным каналом.

73

Руководство по цифровой идентификации

NIST SP 800-63B-4
Июль 2025
Аутентификация и управление аутентификаторами

  • Сообщения и уведомления, направляемые на внеполосные устройства, следует снабжать контекстной информацией для пользователя, например названием сервиса, к которому осуществляется доступ.
  • Внеполосные сообщения следует доставлять единообразно по способу и стилю, чтобы помочь подписчику выявлять потенциально подозрительные запросы аутентификации.

8.1.2.4. Однофакторный OTP

Типичное использование

Пользователи получают доступ к OTP, сгенерированному однофакторным OTP-аутентификатором. Выходные данные аутентификатора обычно отображаются на аутентификаторе, а пользователь вводит их в ходе аутентифицируемого сеанса.

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

  • Выходные данные аутентификатора остаются неизменными не менее одной минуты, но в идеале предоставляют пользователям полные две минуты, как указано в разд. 3.1.4.1. Пользователям необходимо достаточное время для ввода выходных данных аутентификатора, включая перевод взгляда между однофакторным OTP-аутентификатором и экраном ввода.

8.1.2.5. Многофакторный OTP

Типичное использование

Пользователи получают доступ к OTP, сгенерированному многофакторным OTP-аутентификатором, посредством второго фактора аутентификации. OTP обычно отображается на устройстве, и пользователь вручную вводит его в ходе аутентифицируемого сеанса. Второй фактор аутентификации может обеспечиваться каким-либо встроенным средством ввода для ввода пароля либо встроенным биометрическим считывателем (например, считывателем отпечатков пальцев). Также применимы соображения удобства использования для дополнительного фактора (см. разд. 8.1.2.1 для паролей и разд. 8.1.4 для биометрии, используемой в многофакторных аутентификаторах).

К соображениям удобства использования при типичном использовании относятся:

  • Пользовательский опыт при ручном вводе выходных данных аутентификатора
    • Для OTP, основанных на времени, предоставляйте льготный период в дополнение ко времени, в течение которого отображается OTP. Пользователям необходимо достаточное время для ввода выходных данных аутентификатора, включая перевод взгляда между многофакторным OTP-аутентификатором и экраном ввода.
    • Учитывайте ограничения форм-фактора, если пользователи должны разблокировать многофакторный OTP-аутентификатор посредством встроенного средства ввода или вводить выходные данные аутентификатора на мобильных устройствах. Набор текста на небольших устройствах значительно более подвержен ошибкам и требует больше времени, чем набор на традиционной клавиатуре. Более крупные сенсорные области повышают удобство использования при разблокировке многофакторного OTP-аутентификатора или вводе выходных данных аутентификатора на мобильных устройствах.

8.1.2.6. Однофакторный криптографический аутентификатор

Типичное использование

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

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

  • Давайте криптографическим ключам достаточно описательные имена, понятные пользователям, чтобы они могли распознавать и запоминать, какой криптографический ключ следует использовать для какой задачи аутентификации. Это избавляет пользователей от необходимости иметь дело с несколькими криптографическими ключами с похожими и неоднозначными именами. Требование к пользователю выбирать из нескольких криптографических ключей на небольших мобильных устройствах может быть особенно проблематичным, если имена криптографических ключей сокращаются из-за уменьшенного размера экрана.
  • Требование физического ввода (например, нажатия кнопки) для работы однофакторного криптографического аутентификатора может создать трудности в использовании. Например, некоторые USB-порты расположены на задней стороне компьютеров, из-за чего пользователям трудно добраться до порта.
  • Для подключаемых аутентификаторов ограниченная доступность непосредственного интерфейса компьютера (например, USB-порта) может создать трудности в использовании. Например, ноутбуки часто имеют ограниченное число USB-портов, что может вынудить пользователей отключать другие USB-периферийные устройства для использования аутентификатора.

8.1.2.7. Многофакторный криптографический аутентификатор

Типичное использование

Для аутентификации пользователи доказывают владение криптографическим ключом и контроль над ним, а также контроль над фактором активации. Также применимы соображения удобства использования для дополнительного фактора (см. разд. 8.1.2.1 для паролей и разд. 8.1.4 для биометрии, используемой в качестве факторов активации).

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

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

8.1.3. Сводка соображений удобства использования

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

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

8.1.4. Соображения удобства использования для биометрии

В этом разделе представлен обзор общего высокого уровня соображений удобства использования для биометрии. Более подробное рассмотрение удобства использования биометрии приведено в Usability & Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics].

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

Типичное использование

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

Рисунок 3; русские подписи приведены ниже
Соображения удобства использованияПаролиСекреты для поискаВнеполосные устройстваОднофакторный OTPМногофакторный OTPОднофакторный криптографическийМногофакторный криптографический
Типичное использование
Доступность аутентификатора — аутентификаторы находятся в непосредственном распоряжении пользователя•••••••
Простой язык в тексте для пользователя (например, инструкциях, подсказках, уведомлениях, сообщениях об ошибках)•••••••
Разборчивость текста для пользователя или текста, вводимого пользователями•••••••
Ввод незамаскированного текста••••
Поддержка ввода текста — длина 64 символа, копирование и вставка•
Отложенное маскирование при вводе текста•
Достаточное время для ввода текста•••••
Ошибки ввода — необходима чёткая и содержательная обратная связь•••••
Разрешено не менее 10 попыток•••••
Оставшиеся разрешённые попытки — необходима чёткая и содержательная обратная связь•••••
Ограничения форм-фактора•••••••
Расположение и доступность непосредственного интерфейса компьютера, такого как USB-порт••
Требуется физический ввод (например, нажатие кнопки)•
Криптографическим ключам необходимы описательные и понятные имена••
Сложность и размер подсказок•
Аутентификация на вторичном устройстве для доступа к секрету аутентификации•
Постоянное аппаратное подключение не требуется•
Прерывистые события
Повторная аутентификация вследствие неактивности пользователя•••••••
Фиксированная периодическая повторная аутентификация•••••••
Меры по предоставлению технической помощи•••••••
Меры по созданию и изменению паролей•
Рис. 3. Соображения удобства использования по типу аутентификатора
  • Соображения удобства использования отпечатков пальцев:
    • Пользователи должны помнить, какие пальцы они использовали для первоначальной регистрации.
    • Количество влаги на пальце влияет на способность датчика успешно выполнить захват.
    • К дополнительным факторам, влияющим на качество захвата отпечатка пальца, относятся возраст, пол и род занятий (например, у пользователей, работающих с химическими веществами или интенсивно использующих руки в работе, папиллярные линии могут быть повреждены).
  • Соображения удобства использования сравнения лица:
    • Пользователи должны помнить, носили ли они какие-либо предметы (например, очки) во время регистрации, что влияет на точность распознавания лица.
    • Различия в условиях освещения окружающей среды могут влиять на точность распознавания лица.
    • Выражения лица влияют на точность распознавания лица (например, улыбка по сравнению с нейтральным выражением).
    • Положение лица влияет на точность распознавания лица (например, взгляд вниз или в сторону от камеры).
  • Соображения удобства использования сравнения радужной оболочки глаза:
    • Ношение цветных контактных линз может влиять на точность распознавания радужной оболочки глаза.
    • Пользователям, перенёсшим операцию на глазах, после операции может потребоваться повторная регистрация.
    • Различия в условиях освещения окружающей среды могут влиять на точность распознавания радужной оболочки глаза, особенно для радужных оболочек определённых цветов.
Прерывистые события

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

  • Повреждённые отпечатки пальцев или травмы пальцев
  • Грязные, сухие или мокрые руки
  • Ношение перчаток или маски
  • Естественные изменения лица или веса с течением времени
  • Операция на глазах

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

NIST SP 800-63B-4 «Руководство по цифровой идентификации»

Июль 2025 г. «Аутентификация и управление аутентификаторами»

  • Альтернативный метод аутентификации должен быть легкодоступен и о нём должно быть ясно сообщено. От пользователей никогда не следует требовать попытки биометрической аутентификации, и им следует разрешать использовать пароль в качестве альтернативного второго фактора.
  • Следует предусмотреть техническую помощь:
    • Ясно сообщайте информацию о том, как и где получить техническую помощь. Например, предоставьте пользователям ссылку на функцию самообслуживания в Интернете или номер телефона службы поддержки. В идеале предоставляйте достаточную информацию, чтобы пользователи могли самостоятельно восстанавливаться после временных событий без внешнего вмешательства.
    • Информируйте пользователей о факторах, которые могут влиять на чувствительность биометрического датчика (например, о чистоте датчика).

8.2. Аспекты успешного взаимодействия с клиентами

Основной аспект клиентского опыта — предвосхищение потребностей пользовательской группы и предложение вариантов аутентификаторов, подходящих для этой группы. Ниже приведены некоторые примеры проблем пригодности аутентификаторов:

  • Внеполосная аутентификация на основе SMS может быть непригодна для абонентов в сельской местности без услуг мобильной связи.
  • Аутентификаторы OTP могут быть трудны для чтения абонентами с нарушениями зрения.
  • Секреты внеполосной аутентификации, передаваемые посредством голосового телефонного вызова, могут быть трудны для понимания абонентами с нарушениями слуха.
  • Некоторые алгоритмы сопоставления лиц могут работать не одинаково хорошо для всех групп пользователей.
  • У некоторых абонентов могут быть состояния, препятствующие получению отпечатков пальцев, такие как отсутствие пальцев, ухудшенные отпечатки пальцев (например, вследствие работы с химическими веществами или интенсивного использования рук) либо проблемы с ловкостью движений.
  • Стоимость аппаратных аутентификаторов может быть непосильной для некоторых абонентов.
  • Точный ручной ввод паролей может быть труден для абонентов с физическими нарушениями, связанными с подвижностью и ловкостью движений.
  • Некоторые типы аутентификаторов могут быть сложны для абонентов с интеллектуальными нарушениями, нарушениями развития, трудностями обучения или нейрокогнитивными нарушениями.
  • У абонентов с более низким доходом с меньшей вероятностью имеются современные устройства, требуемые некоторыми режимами аутентификации.
  • Абонентам с меньшими технологическими навыками может потребоваться помощь для ввода кодов OTP с одного устройства на другое.

79

NIST SP 800-63B-4 «Руководство по цифровой идентификации»

Июль 2025 г. «Аутентификация и управление аутентификаторами»

  • Малый форм-фактор некоторых аутентификаторов может создавать трудности для определённых пользователей, например пожилых людей и лиц с ограниченной ловкостью движений.

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

80

NIST SP 800-63B-4 «Руководство по цифровой идентификации»

Июль 2025 г. «Аутентификация и управление аутентификаторами»

Ссылки

Этот раздел носит информационный характер.

[Blocklists] Habib H, Colnago J, Melicher W, Ur B, Segreti S, Bauer L, Christin N, Cranor L (2017) Password Creation in the Presence of Blacklists. Proceedings 2017 Workshop on Usable Security (Internet Society, San Diego, CA). https://doi.org/10.14722/usec.2017.23043

[CMVP] National Institute of Standards and Technology (2025), Cryptographic Module Validation Program. Доступно по адресу https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program

[Composition] Komanduri S, Shay R, Kelley PG, Mazurek ML, Bauer L, Christin N, Cranor LF, Egelman S (2011) Of Passwords and People: Measuring the Effect of Password-Composition Policies. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (ACM, New York, NY), pp 2595–2604. Доступно по адресу https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf

[DBSC] W3C (2025) Device Bound Session Credentials. Доступно по адресу https://github.com/w3c/webappsec-dbsc

[E-Gov] E-Government Act of 2002, P.L. 107-347, 116 Stat. 2899, 44 U.S.C. § 101 (2002). Доступно по адресу https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

[EO13681] Obama B (2014) Improving the Security of Consumer Financial Transactions. (The White House, Washington, DC), Executive Order 13681, October 17, 2014. Доступно по адресу https://www.federalregister.gov/d/2014-25439

[FEDRAMP] General Services Administration (2022), How to Become FedRAMP Authorized. Доступно по адресу https://www.fedramp.gov/

[FIDO2] Bradley J, Jones MB, Kumar A, Lindemann R, Verrept J, Waite D (2025) Client to Authenticator Protocol (CTAP). (FIDO Alliance, Beaverton, OR). Доступно по адресу https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html

[FIPS140] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3

[FIPS201] National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3. https://doi.org/10.6028/NIST.FIPS.201-3

81

NIST SP 800-63B-4 «Руководство по цифровой идентификации»

Июль 2025 г. «Аутентификация и управление аутентификаторами»

[FISMA] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. Доступно по адресу https://www.govinfo.gov/app/details/PLAW-113publ283

[IC3] Federal Bureau of Investigation (2024) Annual Reports - Internet Crime Complaint Center (IC3). Доступно по адресу https://www.ic3.gov/AnnualReport/Reports/

[ISO/IEC2382-37] International Standards Organization (2022) Information technology — Vocabulary — Part 37: Biometrics (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/73514.html

[ISO/IEC9241-11] International Standards Organization (2018) ISO/IEC 9241-11 Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/63500.html

[ISO/IEC10646] International Standards Organization (2020) Information technology — Universal coded character set (UCS) (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/76835.html

[ISO/IEC19792] International Standards Organization (2009) Information technology — Security techniques — Security evaluation of biometrics (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/51521.html

[ISO/IEC19795-1] International Standards Organization (2021) Information technology - Biometric performance testing and reporting Part 1: Principles and framework (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/73515.html

[ISO/IEC19989-1] International Standards Organization (2020) Information security — Criteria and methodology for security evaluation of biometric systems — Part 1: Framework (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/72402.html

[ISO/IEC19989-3] International Standards Organization (2020) Information security — Criteria and methodology for security evaluation of biometric systems — Part 3: Presentation attack detection (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/73721.html

[ISO/IEC30107-1] International Standards Organization (2023) Information technology — Biometric presentation attack detection — Part 1: Framework (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/83828.html

[ISO/IEC30107-3] International Standards Organization (2023) Information technology — Biometric presentation attack detection — Part 3: Testing and reporting (ISO, Geneva, Switzerland). Доступно по адресу https://www.iso.org/standard/79520.html

[Managers] Lyastani SG, Schilling M, Fahl S, Backes M, Bugiel S (2018) Better managed than memorized? Studying the Impact of Managers on Password Strength and Reuse. 27th USENIX Security Symposium (USENIX Security 18) (USENIX Association, Baltimore, MD), pp 203–220. Доступно по адресу https://www.usenix.org/conference/usenixsecurity18/presentation/lyastani

82

NIST SP 800-63B-4 «Руководство по цифровой идентификации»

Июль 2025 г. «Аутентификация и управление аутентификаторами»

[NISTIR8062] Brooks S, Garcia M, Lefkovitz N, Lightman S, Nadeau E (2017) An Introduction to Privacy Engineering and Risk Management in Federal Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) NIST IR 8062, January 2017. https://doi.org/10.6028/NIST.IR.8062

[NISTRMF] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-37r2. https://doi.org/10.6028/NIST.SP.800-37r2

[OWASP-session] Open Web Application Security Project (2021) Session Management Cheat Sheet. Доступно по адресу https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

[OWASP-XSS-prevention] Open Web Application Security Project (2021) XSS (Cross Site Scripting) Prevention Cheat Sheet. Доступно по адресу https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

[Persistence] Herley C, Van Oorschot P (2012) A Research Agenda Acknowledging the Persistence of Passwords. IEEE Security & Privacy Magazine, (IEEE, Garden Grove, CA) 10(1):28–36. https://doi.org/10.1109/MSP.2011.150

[Policies] Weir M, Aggarwal S, Collins M, Stern H (2010) Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords. Proceedings of the 17th ACM Conference on Computer and Communications Security, CCS ‘10, (ACM, New York, NY, USA), pp 162–175. https://doi.org/10.1145/1866307.1866327

[PrivacyAct] Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974). Доступно по адресу https://www.govinfo.gov/content/pkg/USCODE-2020-title5/pdf/USCODE-2020-title5-partI-chap5-subchapII-sec552a.pdf

[PSL] Mozilla Foundation (2022) Public Suffix List. Доступно по адресу https://publicsuffix.org/list/

[RBG] National Institute of Standards and Technology (2023) Random Bit Generation. Доступно по адресу https://csrc.nist.gov/projects/random-bit-generation

[RFC20] Cerf V (1969) ASCII format for network interchange. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 20. https://doi.org/10.17487/RFC0020

[RFC5280] Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5280. https://doi.org/10.17487/RFC5280

83

NIST SP 800-63B-4

Digital Identity Guidelines

Июль 2025

Authentication and Authenticator Management

[RFC6749] Hardt D (2012) The OAuth 2.0 Authorization Framework. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6749. https://doi.org/10.17487/RFC6749

[RFC8446] Rescorla E (2018) The Transport Layer Security (TLS) Protocol Version 1.3. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8446. https://doi.org/10.17487/RFC8446

[RFC9325] Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 9325. https://doi.org/10.17487/RFC9325

[Section508] General Services Administration (2022) IT Accessibility Laws and Policies. Доступно по адресу: https://www.section508.gov/manage/laws-and-policies/

[Shannon] Shannon CE (1948) A Mathematical Theory of Communication. Bell System Technical Journal 27(3):379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

[SP800-39] Joint Task Force (2011) Managing Information Security Risk. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-39. https://doi.org/10.6028/NIST.SP.800-39

[SP800-52] McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology), NIST Special Publication (SP) NIST SP 800-52r2. https://doi.org/10.6028/NIST.SP.800-52r2

[SP800-53] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53r5, включает обновления по состоянию на 10 декабря 2020 г. https://doi.org/10.6028/NIST.SP.800-53r5

[SP800-57Part1] Barker EB (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r5. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[SP800-63] Temoshok D, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Choong YY, Proud-Madruga D, Gupta S (2025) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63-4. https://doi.org/10.6028/NIST.SP.800-63-4

[SP800-63A] Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Vachino M (2025) Digital Identity Guidelines: Identity Proofing and Enrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4. https://doi.org/10.6028/NIST.SP.800-63A-4

[SP800-63C] Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid A, Galluzzo R (2025) Digital Identity Guidelines: Federation and Assertions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63C-4. https://doi.org/10.6028/NIST.SP.800-63C-4

[SP800-73pt2] Ferraiolo H, Mehta K, Francomacaro S, Chandramouli R, Gupta S (2024) Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-73pt2-5. https://doi.org/10.6028/NIST.SP.800-73pt2-5

[SP800-90A] Barker E, Kelsey J (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90Ar1. https://doi.org/10.6028/NIST.SP.800-90Ar1

[SP800-90B] Turan MS, Barker E, Kelsey J, McKay K, Baish M, Boyle M (2018) Recommendation for the Entropy Sources Used for Random Bit Generation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90B. https://doi.org/10.6028/NIST.SP.800-90B

[SP800-90C] Barker E, Kelsey J, McKay K, Roginsky A, Turan MS (2024) Recommendation for Random Bit Generator (RBG) Constructions. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) NIST SP 800-90C. https://doi.org/10.6028/NIST.SP.800-90C.4pd

[SP800-131A] Barker E, Roginsky A (2019) Transitioning the Use of Cryptographic Algorithms and Key Lengths. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-131Ar2. https://doi.org/10.6028/NIST.SP.800-131Ar2

[SP800-132] Turan M, Barker E, Burr W, Chen L (2010) Recommendation for Password-Based Key Derivation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-132. https://doi.org/10.6028/NIST.SP.800-132

[SP800-157] Ferraiolo H, Regenscheid AR, Fenton J (2023) Guidelines for Derived Personal Identity Verification (PIV) Credentials. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-157r1 ipd (первоначальный публичный проект). https://doi.org/10.6028/NIST.SP.800-157r1.ipd

[Strength] Kelley PG, Komanduri S, Mazurek ML, Shay R, Vidas T, Bauer L, Christin N, Cranor LF, Lopez J (2012) Guess again (and again and again): Measuring password strength by simulating password-cracking algorithms. 2012 IEEE Symposium On Security and Privacy (SP), с. 523–537. Доступно по адресу: http://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf

[TOTP] M’Raihi D, Machani S, Pei M, Rydell J (2011) TOTP: Time-Based One-Time Password Algorithm. (Internet Engineering Task Force, Reston, VA), RFC 6238. https://doi.org/10.17487/RFC6238

[UsabilityBiometrics] National Institute of Standards and Technology (2008) Usability & Biometrics: Ensuring Successful Biometric Systems. (National Institute of Standards and Technology, Gaithersburg, MD). Доступно по адресу: https://www.nist.gov/system/files/usability_and_biometrics_final2.pdf

[UAX15] Whistler K (2022) Unicode Normalization Forms. (The Unicode Consortium, South San Francisco, CA), Unicode Standard Annex 15, Version 15.0.0, Rev. 53. Доступно по адресу: https://www.unicode.org/reports/tr15/

[WebAuthn] Hodges J, Jones JC, Jones MB, Kumar A, Lundberg E (2021) Web Authentication: An API for accessing Public Key Credentials - Level 2. (World Wide Web Consortium, Cambridge, MA). Доступно по адресу: https://www.w3.org/TR/2021/REC-webauthn-2-20210408/

Приложение A. Надёжность паролей

Это приложение носит информационный характер.

В настоящем приложении для удобства изложения используется слово «пароль». Везде, где оно используется, его следует понимать как включающее парольные фразы и PIN-коды.

A.1. Введение

Пароли являются широко используемой формой аутентификации, несмотря на опасения относительно их использования как с точки зрения удобства использования, так и с точки зрения безопасности [Persistence]. Способность людей запоминать сложные произвольные секреты ограниченна, поэтому они часто выбирают пароли, которые можно легко угадать. Для устранения возникающих вследствие этого проблем безопасности онлайн-сервисы ввели правила, повышающие фактическую надёжность таких паролей. Наиболее примечательной формой являются правила состава, требующие от пользователей выбирать пароли, составленные с использованием смеси типов символов (например, как минимум одной цифры, прописной буквы и символа). Однако анализы скомпрометированных баз данных паролей показывают, что польза таких правил менее значительна, чем первоначально считалось [Policies], а их влияние на удобство использования и запоминаемость существенно.

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

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

A.2. Длина

Длина пароля является основным фактором при характеристике надёжности пароля [Strength] [Composition]. Слишком короткие пароли поддаются атакам полного перебора и словарным атакам. Требуемая минимальная длина пароля зависит от рассматриваемой модели угроз. Онлайн-атаки, при которых атакующий пытается войти в систему, угадывая пароль, можно смягчить ограничением разрешённой частоты попыток входа. Чтобы не позволить атакующему (или настойчивому заявителю с плохими навыками набора текста) быстро осуществить атаку отказа в обслуживании на подписчика, сделав множество неверных попыток, пароли должны быть достаточно сложными, чтобы можно было разрешить разумное число попыток при низкой вероятности успешного угадывания, а ограничение частоты, как описано в разд. 3.2.2, можно было применить до того, как появится значительная вероятность успешного угадывания.

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

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

A.3. Сложность

Правила состава обычно используются в попытке повысить сложность угадывания выбранных пользователями паролей. Однако исследования показали, что пользователи реагируют на требования, налагаемые правилами состава, весьма предсказуемым образом [Policies]. Например, пользователь, который мог бы выбрать «password» в качестве своего пароля, с относительно большой вероятностью выберет «Password1», если требуется включить прописную букву и цифру, или «Password1!», если также требуется символ.

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

Поскольку выбор паролей пользователями часто предсказуем, атакующие, вероятно, угадают пароли, которые ранее уже оказывались успешными. К ним относятся словарные слова и пароли из предыдущих компрометаций, такие как приведённый выше пример «Password1!». По этой причине выбранные пользователями пароли следует сравнивать с блок-листом недопустимых паролей. Этот список должен включать пароли из корпусов данных предыдущих компрометаций, словарные слова, используемые в качестве паролей, и конкретные слова (например, название самого сервиса), которые пользователи, вероятно, выберут. Поскольку требование к минимальной длине также будет регулировать выбор пользователем паролей, этому словарю достаточно включать лишь записи, отвечающие этому требованию. Как отмечено в разд. 3.1.1.2, нецелесообразно, чтобы

NIST SP 800-63B-4
July 2025
Digital Identity Guidelines
Authentication and Authenticator Management

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

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

A.4. Централизованная и локальная проверка

Хотя пароли, используемые как отдельный фактор аутентификации, часто централизованно проверяются проверяющим CSP, пароли, используемые как фактор активации многофакторного аутентификатора, либо проверяются аутентификатором локально, либо используются для формирования вывода аутентификатора, который будет неверным при использовании неправильного фактора активации. Обе эти ситуации называются «локальной проверкой».

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

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

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

89

NIST SP 800-63B-4
July 2025
Digital Identity Guidelines
Authentication and Authenticator Management

A.5. Резюме

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

90

NIST SP 800-63B-4
July 2025
Digital Identity Guidelines
Authentication and Authenticator Management

Приложение B. Синхронизируемые аутентификаторы

Это приложение является нормативным.

B.1. Введение

Возможность «синхронизировать» аутентификаторы — в частности, копировать (то есть клонировать) их секреты аутентификации в облако, а затем в дополнительные аутентификаторы — является относительно новым явлением в аутентификации. В этом приложении приведены дополнительные руководящие указания по использованию синхронизируемых аутентификаторов.

B.2. Клонирование ключей аутентификации

В некоторых случаях ключи аутентификации могут храниться в среде синхронизации (например, в облачном хранилище). Это позволяет создавать резервные копии ключей и передавать их на другие устройства. К ключам, управляемым таким образом, применяются следующие требования:

  • Все ключи ДОЛЖНЫ (SHALL) генерироваться с использованием одобренной криптографии.
  • Ключи аутентификации, клонируемые или экспортируемые с устройства в среду синхронизации, ДОЛЖНЫ (SHALL) храниться только в зашифрованном виде с использованием ключа с минимальной криптографической стойкостью, указанной в последней редакции [SP800-131A] (то есть 112 бит по состоянию на дату настоящей публикации). Эти ключи СЛЕДУЕТ (SHOULD) шифровать методом, использующим секрет, контролируемый пользователем.
  • Все транзакции аутентификации ДОЛЖНЫ (SHALL) выполнять операции с закрытым ключом на локальном устройстве, используя криптографические ключи, сгенерированные на устройстве или восстановленные из среды синхронизации.
  • Ключи аутентификации, хранящиеся в среде синхронизации, ДОЛЖНЫ (SHALL) быть защищены механизмами управления доступом таким образом, чтобы только аутентифицированный пользователь мог получать доступ к своим ключам аутентификации в среде синхронизации.
  • Доступ пользователя к ключам аутентификации в среде синхронизации ДОЛЖЕН (SHALL) быть защищён многофакторной аутентификацией, эквивалентной AAL2, для сохранения целостности протоколов аутентификации, использующих синхронизированные ключи.
  • Эти общие требования и любые другие специфичные для ведомства требования к использованию синхронизируемых аутентификаторов ДОЛЖНЫ (SHALL) быть документированы и доведены до сведения, в том числе на общедоступных веб-сайтах и в политиках цифровых сервисов, где это применимо.
  • Аутентификаторы, позволяющие использовать синхронизируемые ключи аутентификации, СЛЕДУЕТ (SHOULD) снабжать пользовательским интерфейсом (UI), позволяющим подписчикам просматривать сервисы, для которых они создали синхронизируемый ключ аутентификации, был ли этот ключ синхронизирован и куда этот ключ был синхронизирован. UI НЕ ДОЛЖЕН (SHALL NOT) раскрывать сам ключ аутентификации.

91

NIST SP 800-63B-4
July 2025
Digital Identity Guidelines
Authentication and Authenticator Management

Следующие дополнительные требования применяются к использованию синхронизируемых аутентификаторов в федеральных корпоративных системах8:

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

Эти меры управления специально поддерживают синхронизацию, и их следует рассматривать как дополняющие существующие требования к многофакторным криптографическим аутентификаторам и требования AAL2, включая валидацию [FIPS140].

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

B.3. Требования к реализации

Многие синхронизируемые аутентификаторы построены на спецификации W3C [WebAuthn], которая предоставляет общую структуру данных, криптографический протокол запрос—ответ и API для использования учётных данных с открытым ключом. Спецификация является гибкой и адаптивной, то есть не все развёртывания учётных данных WebAuthn будут соответствовать требованиям федеральных ведомств к реализации.

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

8Федеральные корпоративные системы включают системы, считающиеся входящими в сферу действия руководства PIV, такие как государственные подрядчики, государственные служащие и партнёры по выполнению миссии. Они не включают сценарии использования «государство—потребитель» или общедоступные сценарии использования.

92

NIST SP 800-63B-4
July 2025
Digital Identity Guidelines
Authentication and Authenticator Management

В этом разделе описаны определённые флаги в спецификации WebAuthn, которые федеральным ведомствам, выступающим в роли RP, следует понимать и запрашивать при создании своих реализаций синхронизируемых аутентификаторов для соответствия руководящим указаниям AAL2.

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

Присутствие пользователя (UP)

Флаг User Present указывает, что проверка «присутствия» подтвердила взаимодействие пользователя с аутентификатором (например, касание аппаратного токена, вставленного в порт USB). Это поддерживает намерение аутентификации, как описано в разд. 3.2.8. Проверяющим СЛЕДУЕТ (SHOULD) подтверждать, что флаг User Present установлен.

Проверка пользователя (UV)

Флаг User Verified указывает, что аутентификатор локально аутентифицировал пользователя с помощью одного из доступных методов «проверки пользователя». Проверяющие ДОЛЖНЫ (SHALL) указывать, что UV является предпочтительным, и ДОЛЖНЫ (SHALL) проверять ответы, чтобы подтвердить значение флага UV. Это указывает, может ли аутентификатор рассматриваться как многофакторный криптографический аутентификатор. Если пользователь не проверен, ведомства ДОЛЖНЫ (SHALL) рассматривать аутентификатор как однофакторный криптографический аутентификатор. Дополнительное расширение спецификации WebAuthn Level 3 (см. разд. 10.3 [WebAuthn]) предоставляет дополнительные данные о методах проверки, если ведомства стремятся получить контекст о событии локальной аутентификации.

Допускающий резервное копирование

Флаг Backup Eligible указывает, может ли аутентификатор быть синхронизирован с другим устройством (то есть может ли ключ храниться в другом месте). Важно отметить, что возможность синхронизации аутентификатора не означает, что он был синхронизирован. Проверяющие МОГУТ (MAY) использовать этот флаг для установления политик, ограничивающих использование синхронизируемых аутентификаторов. Этот флаг необходим для различения аутентификаторов, привязанных к устройству, и аутентификаторов, которые могут быть клонированы более чем на одно устройство.

Состояние резервного копирования

Флаг Backup State указывает, был ли аутентификатор синхронизирован с другим устройством. Проверяющие МОГУТ (MAY) использовать этот флаг для установления ограничений для аутентификаторов, синхронизированных с другими устройствами. Ведомствам НЕ СЛЕДУЕТ (SHOULD NOT) обусловливать принятие этим флагом для общедоступных приложений ввиду соображений пользовательского опыта.

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

93

NIST SP 800-63B-4 — Руководство по цифровой идентификации
Июль 2025 — Аутентификация и управление аутентификаторами

конкретных аутентификаторов. Для сценариев использования в федеральных корпоративных системах ведомствам СЛЕДУЕТ (SHOULD) реализовать возможности аттестации на основе функциональности, предоставляемой их поставщиками платформ. Это будет иметь форму аттестации производителя, в рамках которой RP запрашивает идентифицирующую информацию об аутентификаторе.

Недоступность аттестаций НЕ СЛЕДУЕТ (SHOULD NOT) использовать как препятствие для применения аутентификаторов, допускающих синхронизацию, в широких публичных приложениях. Из-за ограниченной доступности аттестаций в потребительских продуктах требование их использования, вероятно, направит пользователей к менее безопасным вариантам аутентификации, уязвимым для фишинга (например, к внеполосной аутентификации на основе PSTN). Хотя метаданные транзакции аутентификации (например, флаг User Verified, указывающий на использование локального фактора активации) доступны в ответах WebAuthn, аттестация может обеспечить более высокую уверенность в характеристиках аутентификатора, использованного в транзакции. RP СЛЕДУЕТ (SHOULD) использовать аттестацию для определения уровня уверенности, который они имеют в аутентификаторе, допускающем синхронизацию, когда аттестации доступны.

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

B.4. Совместное использование

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

Как указано в таблице 5, некоторые реализации аутентификаторов, допускающих синхронизацию, приняли такое поведение пользователей и установили способы совместного использования ключей аутентификации между разными пользователями. Кроме того, некоторые реализации активно поощряют совместное использование аутентификаторов, допускающих синхронизацию, как удобную и более безопасную альтернативу совместному использованию паролей для общих сервисов.

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

Риск совместного использования, создаваемый этим новым классом аутентификаторов, не уникален. Он относится ко всем типам аутентификаторов, некоторые из которых слабее аутентификаторов, допускающих синхронизацию. Любой аутентификатор может быть совместно использован пользователем, который твёрдо намерен это сделать. Пользователи могут активно совместно использовать пароли, OTP, внеполосные аутентификаторы и даже события push-аутентификации, которые позволяют назначенному лицу (официально назначенному или нет) проходить аутентификацию от имени конечного пользователя.

Ведомства определяют, какие аутентификаторы они будут принимать для своих приложений, исходя из конкретных рисков, угроз и соображений удобства использования, с которыми они сталкиваются. Аутентификаторы, допускающие синхронизацию, могут предлагаться как новый вариант для приложений, стремящихся реализовать уровень до AAL2. Компромиссы, связанные с этой технологией, следует соотносить с ожидаемыми результатами в области безопасности, конфиденциальности и пользовательского опыта.

B.5. Пример

Распространённое использование аутентификаторов, допускающих синхронизацию, — в транзакции аутентификации AAL2. Следующие пункты обобщают, как аутентификаторы WebAuthn, допускающие синхронизацию, удовлетворяют аспектам требований AAL2:

Устойчивость к фишингу (рекомендуется, требуется для федеральных корпоративных систем)
Достигнуто: Правильно настроенные аутентификаторы, допускающие синхронизацию, создают уникальную пару открытого и закрытого ключей, использование которой ограничено доменом, в котором она была создана (то есть ключ может использоваться только с определённым веб-сайтом или RP). Это не позволяет поддельной веб-странице захватить и повторно использовать результат работы аутентификатора.
Устойчивость к повторному воспроизведению (требуется)
Достигнуто: Аутентификаторы, допускающие синхронизацию, предотвращают устойчивость к повторному воспроизведению (то есть предотвращение повторного использования в будущих транзакциях) посредством случайного nonce, включаемого в каждую транзакцию аутентификации.
Намерение аутентификации (требуется)
Достигнуто: Аутентификаторы, допускающие синхронизацию, требуют от пользователей представить фактор активации (то есть секрет активации, биометрическую характеристику), чтобы инициировать криптографический протокол аутентификации. Это служит намерением аутентификации, поскольку событие не может продолжиться без активного участия пользователя.
Многофакторность (требуется)
Достигнуто: Значение флага User Verified указывает, использовался ли локальный механизм аутентификации (то есть фактор активации) для завершения транзакции. Без верификации пользователя верификатор запрашивает дополнительный фактор аутентификации как часть транзакции.

Если подписчик предоставляет собственный аутентификатор, верификатор может иметь ограниченную видимость функций и возможностей инфраструктуры синхронизации и устройств, с которыми пользователь может синхронизировать свои ключи аутентификации. В этом сценарии верификатору СЛЕДУЕТ (SHOULD) задействовать дополнительные индикаторы риска или сигналы доверия, которые могут быть доступны из транзакции, устройства или инфраструктуры синхронизации, чтобы повысить уверенность в событии аутентификации.

Аутентификаторы, допускающие синхронизацию, не уникальны в этом отношении. Любой предоставленный подписчиком аутентификатор подвержен тем же рискам, что и аутентификаторы, допускающие синхронизацию, включая аутентификаторы OTP и почти все внеполосные аутентификаторы. CSP и IdP важно оценивать каждый тип аутентификатора, который они предлагают на каждом уровне гарантий, и определять, какие из них приемлемы с учётом их пользователей и типов транзакций.

B.6. Соображения безопасности

Аутентификаторы, допускающие синхронизацию, создают отдельные угрозы и проблемы, которые ведомствам следует оценить до внедрения или развёртывания, как показано в таблице 5.

Таблица 5. Угрозы, проблемы и меры противодействия для аутентификаторов, допускающих синхронизацию
Угроза или проблемаОписаниеМеры противодействия
Несанкционированное использование ключа или утрата контроляНекоторые развёртывания аутентификаторов, допускающих синхронизацию, поддерживают совместное использование ключей аутентификации с устройствами, принадлежащими другим пользователям, которые затем могут злоупотребить ключом.Применять функции корпоративного управления устройствами или управляемые профили, предотвращающие совместное использование синхронизированных ключей.
Предоставлять пользователям механизмы для просмотра ключей, статусов ключей, а также того, были ли и где ключи были предоставлены для совместного использования.
Информировать пользователей о рисках несанкционированного использования ключей посредством существующих механизмов повышения осведомлённости и обучения.
Компрометация инфраструктуры синхронизацииДля поддержки синхронизации ключей большинство реализаций клонирует ключи в инфраструктуру синхронизации (то есть облачный сервис, подключённый к нескольким устройствам, связанным с учётной записью).Хранить только зашифрованный ключевой материал.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза или проблемаОписаниеМеры противодействия
Реализовать средства контроля доступа к инфраструктуре синхронизации, которые предотвращают доступ к ключу аутентификации для любого лица, кроме аутентифицированного пользователя.
Оценивать облачные сервисы на предмет базовых функций безопасности (например, защит уровня FISMA moderate или сопоставимых).
Использовать аппаратные модули безопасности для защиты зашифрованных ключей.
Несанкционированный доступ к инфраструктуре синхронизации и восстановлениеСинхронизированные ключи доступны через облачные процессы восстановления учётной записи, что представляет потенциальную слабость аутентификаторов.Реализовать процессы восстановления аутентификации, согласованные с SP 800-63B.
Ограничить возможности восстановления для ключей федеральных корпоративных систем посредством управления устройствами или возможностей управляемой учётной записи.
Привязать несколько аутентификаторов на уровне AAL2 и выше для поддержки восстановления.
Требовать аутентификацию AAL2 для добавления любых новых аутентификаторов для доступа пользователя к инфраструктуре синхронизации.
Использовать синхронизированные ключи только как производный аутентификатор в сценариях федеральных корпоративных систем [SP800-157].
Уведомлять пользователя о любых действиях по восстановлению.

Продолжение на следующей странице

Продолжение с предыдущей страницы

Угроза или проблемаОписаниеМеры противодействия
Использовать секрет, контролируемый пользователем (то есть не известный поставщику инфраструктуры синхронизации), для шифрования и восстановления ключей.
ОтзывПоскольку аутентификаторы, допускающие синхронизацию, используют ключи, специфичные для RP, возможность централизованно отзывать доступ на основе этих ключей затруднена. Например, при традиционной PKI CRL могут централизованно использоваться для отзыва доступа. Аналогичный процесс недоступен для аутентификаторов, допускающих синхронизацию, или любых учётных данных на основе FIDO WebAuthn.Реализовать центральную учётную запись управления идентификацией (IDM), чтобы пользователи могли управлять аутентификаторами и удалять их из учётной записи «домашнего ведомства», если они скомпрометированы или истекли.
Использовать SSO и федерацию, чтобы ограничить число ключей, специфичных для RP, которые потребуется отозвать при инциденте.
Установить политики и инструменты для запроса пользователям периодически проверять ключи на действительность и актуальность.

Приложение C. Список символов, сокращений и акронимов

AAL
Уровень гарантий аутентификации
ASCII
Американский стандартный код для обмена информацией
CAC
Карта общего доступа
CSP
Поставщик услуг учётных данных
CSRF
Подделка межсайтового запроса
DNS
Система доменных имён
FEDRAMP
Федеральная программа управления рисками и авторизацией
FIPS
Федеральные стандарты обработки информации
FMR
Частота ложных совпадений
FNMR
Частота ложных несовпадений
IAL
Уровень гарантий идентификации
IdP
Поставщик удостоверений личности
KBA
Аутентификация на основе знаний

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

MAC
Код аутентификации сообщения

MF
Многофакторный

MFA
Многофакторная аутентификация

NARA
Национальное управление архивов и документации

NFC (протокол связи)
Связь ближнего действия

OTP
Одноразовый пароль

OWASP
Открытый всемирный проект по безопасности приложений

PAD
Обнаружение атак с предъявлением

PIA
Оценка воздействия на конфиденциальность

PIN
Персональный идентификационный номер

PIV
Персональная проверка личности

PKI
Инфраструктура открытых ключей

PSTN
Телефонная сеть общего пользования

QR
Быстрый отклик

100

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

RP
Полагающаяся сторона

SAOP
Старшее должностное лицо ведомства по вопросам конфиденциальности

SF
Однофакторный

SMS
Служба коротких сообщений

SORN
Уведомление о системе записей

SSO
Единый вход

TEE
Доверенная среда выполнения

TLS
Безопасность транспортного уровня

TPM
Доверенный платформенный модуль

USB
Универсальная последовательная шина

VOIP
Передача голоса по IP

XSS
Межсайтовое выполнение сценариев

101

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

Приложение D. Глоссарий

Этот раздел носит информационный характер.

В сфере цифровой идентификации используется большое разнообразие терминов. Хотя многие определения согласуются с более ранними версиями SP 800-63, некоторые из них были изменены в этой редакции. Многие из этих терминов не имеют единого, согласованного определения, что требует тщательно учитывать, как эти термины определены здесь.

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

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

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

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

соискатель
Субъект, проходящий процессы установления личности и регистрации.

одобренная криптография
Алгоритм шифрования, хеш-функция, генератор случайных битов или сходный метод, одобренный Federal Information Processing Standards (FIPS) либо рекомендованный NIST. Одобренные алгоритмы и методы либо указаны, либо приняты в рекомендации FIPS или NIST.

утверждение
Заявление от IdP к RP, содержащее информацию о событии аутентификации подписчика. Утверждения также могут содержать атрибуты идентификации подписчика в форме значений атрибутов, производных значений атрибутов и наборов атрибутов.

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

102

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

аттестация
Информация, передаваемая CSP, как правило, в момент привязки аутентификатора, для описания характеристик подключённого аутентификатора или конечной точки, участвующей в операции аутентификации.

атрибут
Качество или характеристика, приписываемые кому-либо или чему-либо. Атрибут идентификации — это атрибут, относящийся к идентичности подписчика (например, имя, дата рождения, адрес).

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

аутентифицировать
См. аутентификация.

аутентифицированный защищённый канал
Зашифрованный канал связи, использующий одобренную криптографию, в котором инициатор соединения (клиент) аутентифицировал получателя (сервер). Аутентифицированные защищённые каналы шифруются для обеспечения конфиденциальности и защиты от активных посредников и часто используются в процессе аутентификации пользователя. Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS) [RFC9325] являются примерами аутентифицированных защищённых каналов, в которых сертификат, представленный получателем, проверяется инициатором. Если не указано иное, аутентифицированные защищённые каналы не требуют от сервера аутентифицировать клиента. Аутентификация сервера часто выполняется посредством цепочки сертификатов, ведущей к доверенному корню, а не отдельно для каждого сервера.

аутентифицированный сеанс
См. защищённый сеанс.

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

уровень доверия к аутентификации (AAL)
Категория, описывающая надёжность процесса аутентификации.

фактор аутентификации
Три типа факторов аутентификации: то, что вы знаете, то, чем вы обладаете, и то, чем вы являетесь. Каждый аутентификатор имеет один или несколько факторов аутентификации.

103

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

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

ключ аутентификации
Закрытый или симметричный ключ, используемый аутентификатором для формирования вывода аутентификатора.

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

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

аутентификатор
Нечто, чем подписчик владеет и управляет (например, криптографический модуль или пароль) и что используется для аутентификации идентичности заявителя. См. тип аутентификатора и многофакторный аутентификатор.

привязка аутентификатора
Установление связи между определённым аутентификатором и учётной записью подписчика, позволяющей аутентификатору аутентифицировать подписчика, связанного с учётной записью, возможно совместно с другими аутентификаторами.

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

104

NIST SP 800-63B-4 — Руководство по цифровой идентификации (Digital Identity Guidelines)

Июль 2025 г. — Аутентификация и управление аутентификаторами (Authentication and Authenticator Management)

тип аутентификатора
Категория аутентификаторов с общими характеристиками, такими как типы предоставляемых ими факторов аутентификации и механизмы их работы.

аутентичность
Свойство данных происходить из заявленного источника.

авторизовать
Решение предоставить доступ, обычно автоматизированное путём оценки атрибутов субъекта.

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

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

список блокировки
Документированный перечень конкретных элементов, блокируемых в соответствии с решением, установленным политикой. Исторически это понятие было известно как «чёрный список».

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

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

заявленная идентичность
Заявление соискателя о непроверенных и неподтверждённых персональных атрибутах.

105

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

учётные данные
Объект или структура данных, авторитетно связывающие идентичность — посредством идентификатора — и (необязательно) дополнительные атрибуты по меньшей мере с одним аутентификатором, которым владеет и который контролирует подписчик. Учётные данные выдаются, хранятся и поддерживаются CSP. Подписчик может владеть копиями информации из учётных данных, обычно в форме одного или нескольких цифровых сертификатов, которые часто содержатся в аутентификаторе вместе со связанными с ними закрытыми ключами.
поставщик услуг учётных данных (CSP)
Доверенная организация, в функции которой входят установление идентичности заявителей для службы идентификации и регистрация аутентификаторов для учётных записей подписчиков. CSP может быть независимой третьей стороной.
межсайтовая подделка запроса (CSRF)
Атака, при которой подписчик, в настоящее время аутентифицированный для RP и подключённый посредством защищённой сессии, просматривает веб-сайт атакующего, в результате чего подписчик неосознанно вызывает нежелательные действия в RP. Например, если веб-сайт банка уязвим для CSRF-атаки, подписчик может непреднамеренно санкционировать крупный денежный перевод, щёлкнув вредоносную ссылку в электронном письме, пока соединение с банком открыто в другом окне браузера.
межсайтовое выполнение сценариев (XSS)
Уязвимость, позволяющая атакующим внедрять вредоносный код в иной раз безвредный веб-сайт. Эти сценарии получают разрешения сценариев, создаваемых целевым веб-сайтом, чтобы скомпрометировать конфиденциальность и целостность передачи данных между веб-сайтом и клиентами. Веб-сайты уязвимы, если отображают предоставленные пользователем данные из запросов или форм, не очищая данные так, чтобы они не были исполнимыми.
криптографический аутентификатор
Аутентификатор, который доказывает владение секретом аутентификации посредством непосредственной связи с верификатором через криптографический протокол аутентификации.
криптографический ключ
Значение, используемое для управления криптографическими операциями, такими как расшифрование, шифрование, формирование подписи или проверка подписи. Для целей настоящих руководящих указаний требования к ключам должны соответствовать минимальным требованиям, указанным в таблице 2 [SP800-57Part1]. См. асимметричные ключи или симметричные ключи.
криптографический модуль
Набор аппаратных средств, программного обеспечения или микропрограмм, реализующий утверждённые функции безопасности, включая криптографические алгоритмы и генерацию ключей.

106

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

цифровая аутентификация
Процесс установления уверенности в идентичностях пользователей, представленных системе в цифровом виде. В предыдущих редакциях SP 800-63 это называлось «электронной аутентификацией».
цифровая идентичность
Атрибут или набор атрибутов, однозначно описывающий субъект в заданном контексте.
цифровая подпись
Операция с асимметричным ключом, при которой закрытый ключ используется для цифрового подписания данных, а открытый ключ — для проверки подписи. Цифровые подписи обеспечивают защиту подлинности, защиту целостности и поддержку неотказуемости, но не защиту конфиденциальности или защиту от атак повторного воспроизведения.
цифровая транзакция
Дискретное цифровое событие между пользователем и системой, поддерживающее деловую или программную цель.
конечная точка
Любое устройство, используемое для доступа к цифровой идентичности в сети, например ноутбуки, настольные компьютеры, мобильные телефоны, планшеты, серверы, устройства Интернета вещей и виртуальные среды.
регистрация
Процесс, посредством которого CSP/IdP предоставляет успешно прошедшему установление идентичности заявителю учётную запись подписчика и связывает аутентификаторы для предоставления постоянного доступа.
энтропия
Степень неопределённости, с которой сталкивается атакующий при определении значения секрета. Энтропия обычно выражается в битах. Значение с n битами энтропии имеет ту же степень неопределённости, что и равномерно распределённое случайное n-битное значение.
фактор
См. фактор аутентификации.
Федеральные стандарты обработки информации (FIPS)
Стандарты для принятия и использования федеральными департаментами и агентствами, разрабатываемые NIST, подразделением Министерства торговли США. FIPS охватывают темы в области информационных технологий для достижения общих уровней качества, безопасности и совместимости. Документы FIPS доступны в Интернете на домашней странице FIPS: https://www.nist.gov/itl/fips.cfm.

107

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

федерация
Процесс, позволяющий передавать информацию об идентичности и аутентификации между набором сетевых систем.
уровень гарантий федерации (FAL)
Категория, описывающая процесс, используемый в транзакции федерации для передачи стороне RP событий аутентификации и атрибутов подписчика.
хеш-функция
Функция, отображающая битовую строку произвольной длины в битовую строку фиксированной длины. Утверждённые хеш-функции обладают следующими свойствами:
  1. Односторонность — вычислительно неосуществимо найти какой-либо вход, отображаемый в какой-либо заранее заданный выход.
  2. Устойчивость к коллизиям — вычислительно неосуществимо найти любые два различных входа, отображаемых в один и тот же выход.
идентификатор
Объект данных, связанный с одной уникальной сущностью (например, человеком, устройством или сессией) в заданном контексте и никогда не назначаемый какой-либо другой сущности в этом контексте.
идентичность
См. цифровая идентичность.
уровень гарантий идентичности (IAL)
Категория, передающая степень уверенности в том, что заявленная идентичность субъекта является его действительной идентичностью.
свидетельство идентичности
Информация или документация, подтверждающая существование заявленной идентичности в реальном мире. Свидетельство идентичности может быть физическим (например, водительское удостоверение) или цифровым (например, мобильное водительское удостоверение или цифровое утверждение). Свидетельство должно поддерживать как валидацию (то есть подтверждение подлинности и точности), так и верификацию (то есть подтверждение того, что заявитель является истинным владельцем свидетельства).
установление идентичности
Процессы, используемые для сбора, валидации и верификации информации о субъекте с целью установить уверенность в заявленной идентичности субъекта.
поставщик идентичности (IdP)
Сторона в транзакции федерации, которая создаёт утверждение для подписчика и передаёт утверждение RP.

108

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

атака внедрением
Атака, при которой атакующий предоставляет недоверенную биометрическую информацию или носитель в программу или процесс. Например, это может включать внедрение фальсифицированного изображения свидетельства идентичности, поддельного видео пользователя или морфированного изображения, чтобы обойти технологию валидации свидетельств либо биометрические и визуальные сравнения для верификации пользователя.
управляемость
Предоставление возможности детализированного администрирования персональной информации, включая изменение, удаление и выборочное раскрытие. [NISTIR8062]
запоминаемый секрет
См. пароль.
код аутентификации сообщения (MAC)
Криптографическая контрольная сумма данных, использующая симметричный ключ для обнаружения как случайных, так и преднамеренных изменений данных. MAC обеспечивают защиту подлинности и целостности, но не защиту от отказа от совершённых действий.
мобильный код
Исполнимый код, который обычно передаётся от своего источника другой компьютерной системе для исполнения. Эта передача часто осуществляется по сети (например, JavaScript, встроенный в веб-страницу), но также может осуществляться через физические носители.
многофакторная аутентификация (MFA)
Система аутентификации, требующая для успешной аутентификации более одного различного типа фактора аутентификации. MFA может выполняться с использованием многофакторного аутентификатора или путём сочетания однофакторных аутентификаторов, предоставляющих различные типы факторов.
многофакторный аутентификатор
Аутентификатор, предоставляющий более одного различного фактора аутентификации, например криптографическое устройство аутентификации со встроенным биометрическим датчиком, который требуется для активации устройства.
сеть
Открытая среда связи, обычно Интернет, используемая для передачи сообщений между заявителем и другими сторонами. Если не указано иное, сети предполагаются открытыми и подверженными активным (например, выдача себя за другое лицо, перехват сессии) и пассивным (например, подслушивание) атакам в любой точке между сторонами (например, заявителем, верификатором, CSP, RP).

109

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

одноразовое число (nonce)
Значение, используемое в протоколах безопасности, которое никогда не повторяется с тем же ключом. Например, одноразовые числа, используемые как запросы в протоколах аутентификации «запрос — ответ», не должны повторяться до смены ключей аутентификации. В противном случае существует возможность атаки повторного воспроизведения. Использование одноразового числа в качестве запроса является требованием, отличным от случайного запроса, поскольку одноразовое число необязательно является непредсказуемым.
неотказуемость
Способность защитить от ложного отрицания человеком совершения конкретной транзакции.
автономная атака
Атака, при которой атакующий получает некоторые данные (например, путём подслушивания транзакции аутентификации либо проникновения в систему и кражи файлов безопасности), которые атакующий способен анализировать в системе по своему выбору.
сетевая атака
Атака на протокол аутентификации, при которой атакующий либо принимает на себя роль заявителя перед подлинным верификатором, либо активно изменяет канал аутентификации.
атака подбором в сети
Атака, при которой атакующий выполняет повторные попытки входа в систему, угадывая возможные значения вывода аутентификатора.
кодовая фраза
Пароль, состоящий из последовательности слов или другого текста, который заявитель использует для аутентификации своей идентичности. Кодовая фраза сходна с паролем по использованию, но обычно длиннее для повышения безопасности.
пароль
Тип аутентификатора, состоящий из строки символов, предназначенной для запоминания подписчиком или запоминающейся для него, чтобы позволить заявителю продемонстрировать нечто известное ему как часть процесса аутентификации. В первоначальном выпуске SP 800-63B пароли назывались запоминаемыми секретами.
персональный идентификационный номер (PIN)
Пароль, обычно состоящий только из десятичных цифр.
персональная информация
Информация, которую можно использовать для различения или отслеживания идентичности человека либо самостоятельно, либо в сочетании с другой информацией, связанной или допускающей связь с конкретным человеком.

110

NIST SP 800-63B-4
Руководство по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

фарминг
Атака, при которой атакующий вызывает перенаправление подписчика на мошеннический веб-сайт, обычно на мошеннический верификатор/RP в контексте аутентификации. Это может привести к тому, что подписчик раскроет атакующему конфиденциальную информацию (например, пароль), загрузит вредоносное программное обеспечение или окажет содействие мошенническому действию. Это может быть осуществлено путём нарушения работы инфраструктурной службы (например, DNS) или конечной точки подписчика.
фишинг
Атака, при которой подписчика побуждают (обычно посредством электронного письма) взаимодействовать с поддельным верификатором/RP и обманом заставляют раскрыть информацию, которая может использоваться для выдачи себя за этого подписчика перед настоящим верификатором/RP.
устойчивость к фишингу
Способность протокола аутентификации предотвращать раскрытие секретов аутентификации и действительных выводов аутентификатора самозваному верификатору без опоры на бдительность заявителя.
физический аутентификатор
Аутентификатор, владение которым заявитель доказывает как часть процесса аутентификации.
владение и контроль аутентификатора
Способность активировать и использовать аутентификатор в протоколе аутентификации.
предсказуемость
Обеспечение возможности для лиц, владельцев и операторов делать надёжные предположения о персональной информации и её обработке информационной системой. [NISTIR8062]
атака предъявлением
Предъявление подсистеме захвата биометрических данных с целью воспрепятствовать работе биометрической системы.
обнаружение атаки предъявлением (PAD)
Автоматизированное определение атаки предъявлением. Подмножество методов определения атак предъявлением (то есть обнаружение жизнеспособности) включает измерение и анализ анатомических характеристик либо произвольных или непроизвольных реакций, чтобы определить, захватывается ли биометрический образец у живого субъекта, присутствующего в точке захвата.
оценка воздействия на приватность (PIA)
Метод анализа того, как персональная информация собирается, используется, передаётся и поддерживается. PIA используются для выявления и снижения рисков для приватности на протяжении всего

111

NIST SP 800-63B-4
Руководящие указания по цифровой идентификации
Июль 2025
Аутентификация и управление аутентификаторами

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

закрытый ключ

Криптографический ключ, используемый с криптографическим алгоритмом с открытым ключом, который уникально связан с сущностью и не является общедоступным. В криптосистеме с асимметричным ключом (открытым ключом) закрытому ключу соответствует открытый ключ. В зависимости от алгоритма закрытый ключ может использоваться для:

  1. вычисления соответствующего открытого ключа;
  2. создания цифровой подписи, которая может быть проверена с помощью соответствующего открытого ключа;
  3. расшифрования ключей, зашифрованных с помощью соответствующего открытого ключа; или
  4. вычисления общего секрета в ходе транзакции согласования ключей.
защищённый сеанс

Сеанс, в котором сообщения между двумя участниками зашифрованы, а целостность защищена с использованием набора общих секретов, называемых «сеансовыми ключами». Защищённый сеанс считается аутентифицированным, если один участник доказывает владение одним или несколькими аутентификаторами в дополнение к сеансовым ключам и если другая сторона может проверить личность, связанную с аутентификаторами, в ходе сеанса. Если аутентифицированы оба участника, защищённый сеанс считается взаимно аутентифицированным.

псевдоним

Имя, отличное от юридического имени.

псевдонимный идентификатор

Не имеющий смысла, но уникальный идентификатор, который не позволяет RP сделать какие-либо выводы об абоненте, но позволяет RP связать несколько взаимодействий с одним абонентом.

открытый ключ

Криптографический ключ, используемый с криптографическим алгоритмом с открытым ключом, который уникально связан с сущностью и может быть обнародован. В криптосистеме с асимметричным ключом (открытым ключом) открытому ключу соответствует закрытый ключ. Открытый ключ может быть известен любому и, в зависимости от алгоритма, может использоваться для:

  1. проверки цифровой подписи, созданной с использованием соответствующего закрытого ключа;
  2. зашифрования ключей, которые могут быть расшифрованы с использованием соответствующего закрытого ключа; или
  3. вычисления общего секрета в ходе транзакции согласования ключей.
сертификат открытого ключа

Цифровой документ, выданный и подписанный цифровой подписью с использованием закрытого ключа центра сертификации, который связывает идентификатор с открытым ключом абонента. Сертификат указывает, что идентифицированный в нём абонент обладает исключительным контролем над закрытым ключом и доступом к нему. См. также [RFC5280].

инфраструктура открытых ключей (PKI)

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

повторная аутентификация

Процесс подтверждения продолжающегося присутствия абонента и его намерения пройти аутентификацию в ходе сеанса длительного использования.

доверяющая сторона (RP)

Сущность, которая полагается на утверждение верификатора о личности абонента, как правило, для обработки транзакции или предоставления доступа к информации либо системе.

удалённый

Процесс или транзакция, выполняемые через соединённые устройства по сети, а не лично.

атака воспроизведения

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

устойчивость к воспроизведению

Свойство процесса аутентификации противостоять атакам воспроизведения, как правило за счёт использования результата работы аутентификатора, который действителен только для конкретной аутентификации.

ограниченный аутентификатор

Тип, класс или экземпляр аутентификатора, использование которого связано с дополнительным риском ложного принятия и который поэтому подпадает под дополнительные требования.

оценка рисков

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

управление рисками

Программа и поддерживающие процессы, управляющие риском информационной безопасности для деятельности организации (то есть её миссии, функций, имиджа, репутации), активов организации, физических лиц и других организаций и включающие: (i) установление контекста деятельности, связанной с рисками; (ii) оценку риска; (iii) реагирование на риск после его определения; и (iv) мониторинг риска во времени.

соль

Несекретное значение, используемое в криптографическом процессе, обычно для обеспечения того, чтобы результаты вычислений для одного экземпляра не могли быть повторно использованы атакующим.

старшее должностное лицо агентства по вопросам приватности (SAOP)

Лицо, ответственное за обеспечение соблюдения агентством требований к приватности, управление рисками приватности и учёт последствий для приватности всех действий и политик агентства, затрагивающих персональную информацию.

сеанс

Постоянное взаимодействие между абонентом и конечной точкой — либо RP, либо CSP. Сеанс начинается с события аутентификации и завершается событием завершения сеанса. Сеанс привязан посредством использования секрета сеанса, который программное обеспечение абонента (например, браузер, приложение, ОС) может предъявить RP, чтобы доказать связь сеанса с событием аутентификации.

атака захвата сеанса

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

общий секрет

Секрет, используемый при аутентификации и известный абоненту и верификатору.

атака по побочному каналу

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

однофакторный

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

единый вход (SSO)

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

социальная инженерия

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

субъект

Человек, организация, устройство, аппаратное обеспечение, сеть, программное обеспечение или услуга. В настоящих руководящих принципах субъектом является физическое лицо.

абонент

Физическое лицо, зарегистрированное в службе идентификации CSP.

учётная запись абонента

Учётная запись, созданная CSP для каждого абонента, зарегистрированного в его службе идентификации, которая содержит информацию об абоненте и запись о любых аутентификаторах, зарегистрированных для этого абонента.

симметричный ключ

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

синхронизирующая среда

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

синхронизируемые аутентификаторы

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

система записей (SOR)

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

уведомление о системе записей (SORN)

Уведомление, которое федеральные агентства публикуют в Federal Register для описания своей системы записей.

токен

См. аутентификатор.

транзакция

См. цифровая транзакция.

безопасность транспортного уровня (TLS)

Протокол аутентификации и безопасности, широко реализованный в браузерах и веб-серверах. TLS обеспечивает конфиденциальность, аутентификацию на основе сертификата принимающей конечной точки (сервера) и аутентификацию на основе сертификата исходящей конечной точки (клиента). TLS определён в [RFC8446] и [SP800-52].

удобство использования

Степень, в которой продукт может использоваться указанными пользователями для достижения указанных целей с результативностью, эффективностью и удовлетворённостью в указанном контексте использования. [ISO/IEC9241-11]

валидация

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

верификация

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

верификатор

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

выдача себя за верификатора

См. фишинг.

Приложение E. Журнал изменений

Это приложение носит информационный характер.

В этом приложении приведён обзор изменений, внесённых в SP 800-63B с момента его первоначального выпуска.

  • Удаляет нумерованные разделы «Назначение», «Определения» и «Сокращения» и соответствующим образом перенумеровывает разделы. Номера разделов, на которые приведены ссылки ниже, являются новыми номерами разделов.
  • Изменяет название «запоминаемые секреты» на «пароли».
  • Раздел 2: Описывает использование индикаторов мошенничества вместо предварительных проверок аутентификации.
  • Раздел 2.3.2: Снижает требуемый уровень валидации FIPS 140 для аутентификаторов на AAL3.
  • Раздел 2.3.2: Требует на AAL3 неэкспортируемый криптографический аутентификатор вместо аппаратного аутентификатора.
  • Раздел 3.1.1.2: Увеличивает минимальную длину паролей, используемых как единственный фактор аутентификации.
  • Раздел 3.1.3: Не допускает сравнение секретов из основного и вторичного каналов для внеполосной аутентификации.
  • Раздел 3.1.3.1: Снимает запрет на использование телефонных номеров VoIP для внеполосной аутентификации.
  • Раздел 3.1.3.4: Признаёт многофакторные внеполосные аутентификаторы, для которых требуется фактор активации.
  • Разделы 3.1.4 и 3.1.5: Удаляет «устройства» из названия аутентификатора, чтобы учесть приложения OTP.
  • Разделы 3.1.6 и 3.1.7: Удаляет различие между «программным обеспечением» и «устройством» из названия аутентификатора и называет их «характеристиками аутентификатора».
  • Раздел 3.1.7.3: Добавляет требования для аутентификации с использованием кошельков, контролируемых абонентом.
  • Раздел 3.1.7.4 и приложение B: Добавляет требования для синхронизируемых аутентификаторов.
  • Раздел 3.2.3: Обновляет требования и метрики производительности биометрии.
  • Раздел 3.2.3.2: Требует PAD для распознавания лиц и запрещает биометрическое сравнение на основе голоса.
  • Раздел 3.2.5: Добавляет определение и обновляет требования к аутентификаторам, устойчивым к фишингу.

NIST SP 800-63B-4
Июль 2025

Руководящие указания по цифровой идентификации
Аутентификация и управление аутентификаторами

  • Раздел 3.2.10: Устанавливает отдельные требования к локально проверяемым запоминаемым секретам, известным как секреты активации
  • Раздел 3.2.11: Добавляет требования к аутентификаторам, подключённым через беспроводные технологии, такие как NFC и Bluetooth
  • Раздел 3.2.11.3: Признаёт гибридные соединения классом подключённых аутентификаторов
  • Раздел 3.2.12: Централизует требования к случайным значениям, используемым во всём документе
  • Раздел 3.2.13: Добавляет новый раздел о требованиях к неэкспортируемости секретов аутентификатора
  • Раздел удалён: Удаляет устойчивость к компрометации верификатора как отдельно обозначенное требование, поскольку она, как правило, является характеристикой выбранного типа аутентификатора
  • Раздел 4: Переименовывает раздел в «Управление событиями аутентификатора»
  • Раздел 4.1.1: Переносит привязку при регистрации в SP 800-63A
  • Раздел 4.1.2.1: Обобщает привязку дополнительного аутентификатора для всех AAL
  • Раздел 4.1.2.2: Добавляет требования к привязке аутентификаторов, не подключённых к конечной точке
  • Раздел 4.2: Пересматривает требования и методы восстановления учётной записи
  • Раздел 4.6: Пересматривает требования к уведомлениям, направляемым подписчикам
  • Раздел 5.1: Признаёт использование привязанных к устройству учётных данных сеанса
  • Раздел 5.1.1: Добавляет требования к cookie-файлам браузера, используемым для поддержания сеанса
  • Раздел 5.2: Пересматривает требования к повторной аутентификации, чтобы определить здесь общую структуру повторной аутентификации и указать значения тайм-аутов в требованиях AAL
  • Раздел 5.3: Добавляет руководящие указания по использованию мониторинга сеанса (непрерывной аутентификации)

118