Стандарт для паролей: требования 2024 года

Требования, которые онлайн-сервисы предъявляют при проверке своих пользователей, — будь то длина пароля, обязательное указание номера телефона или необходимость биометрической проверки с подмигиванием, зачастую регулируются индустриальными стандартами. Одним из важнейших документов в этой сфере является NIST SP 800-63, Digital Identity Guidelines, разработанный Национальным институтом стандартов и технологий США. Требования этого стандарта обязательны для выполнения всеми государственными органами страны и всеми их подрядчиками, но на практике это означает, что их выполняют все крупнейшие IT-компании и действие требований ощущается далеко за пределами США.

Даже организациям, которые не обязаны выполнять требования NIST SP 800-63, стоит глубоко ознакомиться с его обновленными требованиями, поскольку они зачастую берутся за основу регуляторами в других странах и индустриях. Более того, свежий документ, прошедший четыре раунда публичных правок с индустриальными экспертами, отражает современный взгляд на процессы идентификации и аутентификации, включая требования к безопасности и конфиденциальности, и с учетом возможного распределенного (федеративного) подхода к этим процессам. Стандарт практичен и учитывает человеческий фактор — то, как пользователи реагируют на те или иные требования к аутентификации.

В новой редакции стандарта формализованы понятия и описаны требования к:

• passkeys (в стандарте названы syncable authenticators);
• аутентификации, устойчивой к фишингу;
• пользовательским хранилищам паролей и доступов — кошелькам (attribute bundles);
• регулярной реаутентификации;
• сессионным токенам.

Итак, как нужно аутентифицировать пользователей в 2024 году?

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

Стандарт описывает три уровня гарантий (Authentication Assurance Level, AAL), где AAL1 соответствует самым слабым ограничениям и минимальной уверенности в том, что входящий в систему пользователь — тот, за кого себя выдает. Уровень AAL3 дает самые сильные гарантии и требует более строгой аутентификации. Только на уровне AAL1 допустим единственный фактор аутентификации, например просто пароль.

Требования к паролям таковы:

• паролем считается только централизованно проверяемый секрет, который отправляется пользователем на сервер по защищенному каналу. Локально хранимые и проверяемые пароли называются «активационными секретами», и требования к ним другие;
• запрещены пароли короче 8 символов, рекомендованный минимум — 15 символов;
• запрещено использовать в парольной политике требование регулярно менять пароли по графику, это признано устаревшей практикой;
• запрещено предъявлять требования к составу пароля («ваш пароль должен содержать букву, цифру и значок»);
• рекомендовано разрешить к применению в паролях любые видимые значки ASCII, пробелы и большинство символов Unicode (смайлики и прочее);
• ограничение на максимальную длину пароля, если оно установлено, должно быть хотя бы 64 символа;
• запрещено обрезать пароли при проверке, но разрешается убирать пробелы в начале и конце пароля, если они могут помешать успешной аутентификации;
• запрещено использовать и хранить в системах подсказки к паролям, а также «проверочные вопросы» вроде «девичья фамилия вашей матери»;
• обязательно предотвращать установку часто используемых паролей, то есть иметь стоп-лист популярных паролей или паролей из утечек;
• при обнаружении компрометации паролей (например, появление пароля в утечках) их нужно немедленно сбрасывать;
• при вводе паролей обязательно ограничивать частоту попыток ввода (rate limit) и число неудачных попыток.

Активационные секреты

Это пин-коды и локальные пароли, ограничивающие доступ к хранилищу ключей на устройстве. Они могут быть только числовыми, рекомендуемая минимальная длина — 6 знаков, но допустимы коды от 4 знаков. Для уровня AAL3 основной криптографический секрет (passkey и тому подобное) должен храниться в специальном чипе, препятствующем извлечению данных, и расшифровываться он должен с применением активационного секрета. Для AAL1 и AAL2 достаточно, чтобы ключ ограничивал доступ посторонних и чтобы число попыток ввода ограничивалось, — не больше 10 попыток. После этого хранилище блокируется и требуется применить другой способ аутентификации.

Многофакторная аутентификация (MFA)

Рекомендовано применять MFA на всех уровнях AAL, но если для AAL1 это просто рекомендация, то для AAL2 — обязательное требование, а для AAL3 годятся лишь методы MFA, устойчивые к фишингу.

Устойчивыми считаются только криптографические методы аутентификации: USB-токены, passkeys, а также криптографические ключи, хранящиеся в цифровых кошельках, соответствующих требованиям раздела SP 800-63C (распределенные сервисы идентификации и аутентификации). Все криптографические секреты должны храниться в системах, не допускающих извлечения ключей (TPM, Secure Enclave и подобных). Стандарт допускает синхронизацию ключей между устройствами и их хранение в облачных системах, при условии, что каждое из этих устройств соответствует требованиям стандарта. Именно эти формулировки позволяют использовать passkeys на всех устройствах в экосистеме Android и iOS.

Для обеспечения устойчивости к фишингу требуется реализовать привязку аутентификации к каналу связи или имени проверяющего сервиса (channel binding, verifier name binding). Примерами реализации этих подходов является аутентифицируемое клиентом TLS-соединение и протокол WebAuthn из спецификации FIDO2. Проще говоря, клиент средствами криптографии проверяет, что устанавливает соединение именно с оригинальным сервером, а не подделкой, созданной для AitM-атак.

Зависящие от времени одноразовые пароли (TOTP) из приложений-аутентификаторов, SMS-коды и одноразовые коды со скретч-карт или конвертов являются неустойчивыми к фишингу, но их применение допускается для сервисов с AAL1 и AAL2. Авторы стандарта уделили внимание тому, какие способы работы с одноразовыми кодами вообще нельзя отнести к многофакторной аутентификации и требуется исключить. Нельзя пересылать одноразовые коды на e-mail или номера IP-телефонии — они должны передаваться по каналу связи, отдельному от ведущегося процесса аутентификации. Допускаются OTP, присылаемые через SMS и традиционную телефонную линию, даже если оба соединения (например, Интернет и SMS) установлены, по сути, на одном устройстве.

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

Использование биометрических факторов ограничено стандартом — они могут быть одним из факторов аутентификации, но использование биометрии для идентификации запрещено. Биометрические проверки должны быть дополнительным фактором аутентификации в сочетании с проверкой физического обладания (смартфоном, токеном и так далее — something you have).

Оборудование и алгоритмы биометрической проверки должны гарантировать число ложноположительных идентификаций (FMR) не более 1 из 10 000, ложноотрицательных (FNMR) — не более 5%. Эти показатели должны обеспечиваться для людей любого пола и расы. Алгоритм проверки должен защищать от атак с презентацией (PAD), в которых сенсору демонстрируется фото или видеозапись вместо живого человека.

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

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