Skip to content
Назад в блог

Как исследования изменили рекомендации NIST по паролям

6 мин. чтения
Как исследования изменили рекомендации NIST по паролям

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

Рекомендации NIST изменились не после одного внезапного открытия. К редакции 2017 года накопились исследования реальных утечек, лабораторные эксперименты и наблюдения за сменой паролей, а документ SP 800-63B собрал их в более практичную модель защиты. Финальная редакция 2025 года продолжила это направление и сделала несколько прежних рекомендаций обязательными.

Почему composition rules давали меньше, чем обещали

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

В исследовании Of Passwords and People разные composition policies сравнивались не только по формальным правилам, но и по создаваемым паролям, запоминаемости и пользовательским затратам. Другие работы атаковали большие наборы раскрытых паролей и показали, что привычные метрики политики плохо отражают порядок реальных догадок. NIST суммирует этот результат прямо: правила состава дают меньшую пользу, чем предполагалось, а их влияние на удобство и запоминаемость остаётся серьёзным.

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

Почему плановая ротация тоже потеряла статус нормы

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

Исследование 2010 года The Security of Modern Password Expiration анализировало историю более 7 700 учётных записей и строило догадки для нового пароля на основе предыдущего. Авторы обнаружили, что последовательные значения нередко связаны предсказуемыми преобразованиями, поэтому знание старого пароля заметно облегчало поиск нового. Последующие пользовательские исследования уточняли детали и не подтверждали все предполагаемые негативные эффекты, но также не находили убедительного общего выигрыша от обязательной ротации.

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

Сравнение устаревших политик состава и ротации паролей с генерацией длинных случайных последовательностей

Что действительно написано в редакции 2017 года

Первая финальная версия NIST SP 800-63B вышла в 2017 году и относилась к удалённой аутентификации в системах цифровой идентификации. Это важная граница: документ задаёт требования для федерального контекста США и служит авторитетным ориентиром для индустрии, но не является универсальным законом для каждого сайта.

Для выбранного пользователем memorized secret редакция 2017 года устанавливала минимум 8 символов и рекомендовала разрешать длину как минимум до 64 символов, включая пробелы и Unicode. При создании или смене значение требовалось сравнивать со списком распространённых, ожидаемых и скомпрометированных вариантов. Сервис также должен был ограничивать число неудачных попыток и хранить пароль в виде стойкого к офлайн-атаке солёного хэша с настраиваемой стоимостью вычисления.

Composition rules и произвольная периодическая смена получили формулировку SHOULD NOT, то есть сильную рекомендацию не использовать их без веской причины. Документ также советовал разрешать вставку, чтобы не мешать password managers. Таким образом, редакция 2017 года не просто заменила «сложность» длиной: она перенесла внимание на полный путь защиты, куда входят отбраковка очевидных значений, rate limiting, безопасное хранение и удобство работы с уникальными паролями.

Что усилила редакция 2025 года

В июле 2025 года NIST выпустил финальную SP 800-63B-4. Для пароля как единственного фактора минимальная длина выросла до 15 символов. Если пароль используется только в многофакторном процессе, сервис может разрешить более короткое значение, но не менее 8 символов. Это послабление относится к центрально проверяемому паролю внутри MFA; локальные PIN и другие activation secrets регулируются отдельным разделом.

Запреты на дополнительные composition rules и плановую смену получили нормативное SHALL NOT. При свидетельстве компрометации смена, наоборот, обязательна. Сервис должен проверять весь новый пароль по blocklist распространённых, ожидаемых или ранее раскрытых значений, отклонять совпадение и объяснять пользователю причину. Проверять отдельные содержащиеся внутри слова стандарт не требует.

Редакция 2025 года также требует разрешать password managers и autofill, рекомендует поддерживать вставку и предлагает кнопку показа введённого пароля. Максимальная разрешённая длина должна составлять как минимум 64 символа; печатные ASCII-знаки и пробел следует принимать, Unicode тоже рекомендуется поддерживать с нормализацией. При этом NIST отдельно напоминает, что обычный пароль не является phishing-resistant authenticator, какой бы длинной ни была строка.

Blocklist не обязательно означает отправку пароля внешнему сервису. Список можно проверять локально; другой вариант предлагает Pwned Passwords, где клиент хэширует пароль и передаёт только первые пять символов SHA-1-хэша, после чего сравнивает полный суффикс у себя. Такая проверка отвечает на вопрос, встречалось ли значение в известном корпусе, но отсутствие совпадения ещё не доказывает его стойкость.

Где формула энтропии полезна, а где вводит в заблуждение

Для генератора, который независимо и равномерно выбирает каждый из N символов, пространство из L позиций содержит N^L вариантов. Его энтропия равна L × log₂(N). Двенадцать случайных строчных латинских букв дают примерно 56,4 бита, а восемь случайных символов из 95 печатных ASCII-знаков около 52,6 бита. В этой строго заданной модели дополнительная длина действительно может дать больше, чем несколько новых категорий.

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

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

Что делает Password Generator

Password Generator создаёт случайную часть пароля через crypto.getRandomValues и использует rejection sampling, чтобы убрать смещение от операции остатка. Длина настраивается от 4 до 128 символов, а алфавит собирается из заглавных и строчных латинских букв, цифр и набора знаков. Можно исключить похожие символы, запретить повторы, добавить или убрать конкретные знаки и потребовать определённую категорию в первой позиции.

Индикатор показывает верхнюю оценку log₂(размер алфавита) × количество случайных позиций. Инструмент честно не считает вставленное фиксированное слово случайным и предупреждает, если после него остаётся слишком мало генерируемых знаков. Однако обязательное присутствие выбранных категорий, запрет повторов и фиксированное начало всё равно делают точное распределение уже, поэтому число следует читать как ориентир, а не как сертификат стойкости.

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

Последнее различие особенно важно. Инструмент генерирует секрет, но не реализует политику NIST целиком: он позволяет выбрать длину меньше нормативного минимума, не знает контекст single-factor или MFA и не содержит blocklist. Для отдельной учётной записи практичный сценарий состоит в том, чтобы выбрать допустимую сервисом большую длину, сохранить уникальный результат в менеджере и включить phishing-resistant MFA, если сервис его предлагает.

Похожие инструменты

Частые вопросы

Что NIST рекомендовал для паролей в 2017 году?

Первая редакция SP 800-63B требовала не менее 8 символов для выбранного пользователем пароля, проверку по списку распространённых и скомпрометированных значений, а также защиту от массовых попыток входа. Она рекомендовала не вводить дополнительные composition rules и не заставлять пользователя менять пароль без признаков компрометации.

Что изменилось в NIST SP 800-63B-4 в 2025 году?

Финальная редакция требует минимум 15 символов, если пароль является единственным фактором, и допускает минимум 8 символов, если он применяется только как часть MFA. Запреты на обязательный состав и периодическую смену стали нормативными, а сервисы теперь обязаны разрешать password managers и autofill.

Почему NIST отказался от обязательных заглавных букв, цифр и символов?

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

Нужно ли регулярно менять надёжный пароль?

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

Можно ли точно оценить стойкость любого пароля в битах энтропии?

Нет. Формула L × log₂(N) точна для процесса, который независимо и равномерно выбирает L символов из алфавита размера N. Она не описывает придуманные человеком пароли, словарные фразы и генераторы с дополнительными ограничениями. Реальная стоимость атаки также зависит от порядка догадок, ограничения попыток и способа хранения хэша.

Автор

Fullstack Engineer

В коммерческой разработке с 2011 года — больше 15 лет. Автор двух SaaS-продуктов: TeleGo.io и LingvoHabit.com. Статьи здесь выросли из реальной клиентской и продуктовой работы.

Подробнее об автореНаписать в Telegram

Похожие статьи

SYSTEMD
SYSTEMD · '26

systemd Builder: как Linux перешёл от init-скриптов к unit-файлам

Почему Linux-дистрибутивы перешли от SysV-скриптов к systemd: зависимости сервисов, активация по сокету, cgroups и спор о границах проекта.

#systemd #Lennart Poettering #SysV init #Linux systemd #unit файлы #systemd controversy
6 мин. чтения
COMMAND EXPLAINER
COMMAND EXPLAINER · '26

Command Explainer: как читать man-страницы и понимать Unix

Первая man-страница написана в 1971 году для UNIX. Документация остаётся главным источником знаний. Объясняем сложные команды простым языком — от tar до awk.

#Command Explainer #man pages #Unix philosophy #CLI документация #Linux команды #awk sed tar
3 мин. чтения
ВЗЛОМ САЙТА
ВЗЛОМ САЙТА · '26

Неавторизованная реклама на сайте: как найти взлом и веб-шеллы (разбор реального кейса)

Владелец сайта заметил чужую рекламу Google, которую сам не подключал. Пошаговое расследование: от grep по базе до обнаружения PNG-полиглотов с PHP-шеллом и техники CosmicSting в Magento.

#Взлом сайта #Malvertising #Веб-шеллы #Безопасность #Magento #CosmicSting #Incident Response
5 мин. чтения