Требования, которые онлайн-сервисы предъявляют при проверке своих пользователей, — будь то длина пароля, обязательное указание номера телефона или необходимость биометрической проверки с подмигиванием, зачастую регулируются индустриальными стандартами. Одним из важнейших документов в этой сфере является 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) и количества неудачных попыток.
Бизнес — Блог Касперского
