Плановая смена паролей: разбор темы и аргументов

Вместо вступления

В предыдущей статье про таблицу Hive Systems я вскользь упомянул рекомендацию NIST: менять пароль при компрометации, а не по календарю. Этот пункт вызвал в комментариях дискуссию, которая оказалась содержательнее самой статьи.

Основные возражения:

• проверка на компрометацию опирается на публичные базы утечек, а непубличные наборы существуют и никем не отслеживаются;

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

• смена пароля попутно завершает активные сессии, о которых пользователь мог не знать;

• довод «пользователей это раздражает» слаб: гигиенические привычки тоже раздражают, но их соблюдают.

Ни одно из этих возражений не снимается ссылкой на авторитет NIST. Разберём тему целиком — и начнём не с аргументов, а с того, как эти аргументы устроены.

1. Обратная логика: почему спор о ротации обычно ведётся неправильно

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

1.1. Как система защиты строится по правилам

Нормативный порядок построения системы защиты информации закреплён и в российских, и в международных документах, и он один и тот же.

Приказ ФСТЭК России от 11 апреля 2025 г. № 117 (заменил приказ № 17 с 1 марта 2026 г.) выстраивает последовательность: определение объекта защиты и класса защищённости → моделирование угроз безопасности информации → определение мер, нейтрализующих актуальные угрозы → внедрение → оценка. Аналогично устроена «Методика оценки угроз безопасности информации» ФСТЭК России от 5 февраля 2021 г.: сначала негативные последствия, объекты воздействия, источники и сценарии, и только затем — меры. ГОСТ Р ИСО/МЭК 27001 идёт тем же путём: риск сначала, обработка риска потом.

Логическое направление здесь строго одностороннее:

угроза → мера

Мера существует потому, что существует угроза, которую она снижает. Самостоятельного основания у меры нет.

1.2. Как ротация обосновывается в реальных спорах

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

Рассуждение идёт так:

1. Есть мера: менять пароль раз в 90 дней. Она уже внедрена, записана в регламенте, привычна.

2. Задаётся вопрос: а вдруг она всё-таки полезна?

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

4. Сценарий объявляется актуальной угрозой.

5. Делается вывод: мера обоснована.

Направление обратное:

мера → подбор угрозы под меру

Из пространства возможных сценариев выбирается тот единственный, в котором мера работает, и объявляется репрезентативным.

1.3. Почему это не работает как метод

У обратной логики есть свойство, которое сразу её дисквалифицирует: она обосновывает всё что угодно.

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

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

Отсюда практический тест, который я предлагаю применять к любой спорной мере:

Сформулируйте условия, при которых вы признали бы эту меру ненужной.

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

Что это не умозрительная конструкция, показали Habib с соавторами (SOUPS 2018): их участники подавляющим большинством считали регулярную смену пароля важной для безопасности — и объясняли это тем, что слышат такой совет постоянно. Повторяемый совет усваивается независимо от того, есть ли под ним свидетельства. Подробнее об этой работе — в разделе 7.1.

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

1.4. Что из этого следует для структуры разбора

Раз прямой ход идёт от угроз к мерам, то и разбирать надо в этом порядке. Поэтому дальше: сначала разберёмся с ключевым понятием, вокруг которого крутится весь спор (раздел 2), затем посмотрим, откуда мера взялась исторически (раздел 3), затем выполним прямой ход на конкретном примере (раздел 4) — и только потом вернёмся к аргументам сторон.

2. Компрометация и утечка: это не одно и то же

Весь спор о ротации держится на слове «компрометация». NIST требует смены пароля при наличии свидетельств компрометации. Методический документ ФСТЭК России от 12 апреля 2026 г. в мере ИАФ.3 требует в составе управления аутентификаторами «блокирование (прекращение действия) и замену утерянных, скомпрометированных или поврежденных аутентификаторов». И в обсуждениях компрометацию почти всегда читают как утечку. Это разные вещи, и различие содержательное.

Утечка (нарушение конфиденциальности) — свершившийся факт: защищаемая информация стала доступна лицу, не имеющему на неё права. Это событие во внешнем мире. Оно объективно и не зависит от того, стало ли о нём известно. В терминологии ГОСТ Р 50922-2006 сюда относятся разглашение, несанкционированный доступ, утечка по техническим каналам.

Компрометация — утрата оснований доверять секрету. Российская традиция определения пришла из криптографии: компрометацией считается любое событие, дающее основания полагать, что ключ мог стать известен посторонним. Инструкция, утверждённая приказом ФАПСИ от 13 июня 2001 г. № 152, перечисляет такие события — от утраты ключевого носителя до случаев, когда невозможно достоверно установить, что с носителем происходило. Показателен и обратный пример из того же документа: <cite index=»28-1″>осмотр ключевых носителей многократного использования посторонними лицами не рассматривается как подозрение в компрометации, если при этом исключалась возможность их копирования.</cite>

Различие укладывается в одну фразу:

Утечка — это факт о мире. Компрометация — это факт о нашем знании.

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

Из этого следуют три вещи, важные для всего дальнейшего разбора.

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

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

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

Теперь можно сформулировать точно, что именно компенсирует плановая смена. Не «неизвестные утечки». Она компенсирует необнаруженную компрометацию — тот остаток, о котором организация не узнала ни изнутри, ни снаружи. Объём остатка не константа, а функция зрелости наблюдения.

И отсюда развилка, к которой я ещё вернусь:

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

• если не обнаружена, плановая смена бьёт вслепую.

Ротация не выигрывает ни в одном из двух случаев. Она осмысленна только как замена отсутствующему наблюдению — ровно это зафиксировал PCI DSS v4.0, разрешив в требовании 8.3.9 отказаться от 90-дневной смены в обмен на динамический анализ состояния учётных записей.

3. Откуда взялись 90 дней

Требование периодической смены пароля старше большинства систем, в которых оно сегодня настроено. Спросите, откуда оно взялось, — и почти наверняка услышите про документ Министерства обороны США CSC-STD-002-85 «Department of Defense Password Management Guideline» от 12 апреля 1985 года, известный по цвету обложки как «зелёная книга».

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

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

Это само по себе показательно и прямо связано с разделом 1. Мера, отделённая от своего расчёта, иначе как задним числом подобранными угрозами защищаться и не может: обоснование потерялось по дороге, а мера осталась — и обосновывать её приходится заново, чем придётся.

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

3.1. Что там посчитано

Приложение C вводит четыре параметра:

• L — максимальный срок, в течение которого пароль может использоваться;

• P — приемлемая вероятность того, что пароль будет угадан за этот срок при непрерывном подборе;

• R — число попыток в единицу времени, которое возможно сделать;

• S — мощность пространства паролей.

И связывает их соотношением P = L × R / S — вывод дан в приложении F через обычную комбинаторику. Дальше S = A^M, где A — размер алфавита, M — длина пароля.

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

3.2. Откуда взяли R: скорость линии

Теперь самое любопытное. Откуда в 1985 году брали скорость подбора?

Из скорости модемной линии. Пример в разделе C.6 взят из реальной сети, поддерживавшей сервисы 300 и 1200 бод. Экспериментально измерили: около 8,5 попыток в минуту на 300 бод и около 14 попыток в минуту на 1200 бод.

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

R — управляемый параметр защиты. Это ключ ко всему дальнейшему.

3.3. Результат расчёта: срок жизни почти ни на что не влияет

Подставим. P = 10⁻⁶, R = 8,5 в минуту, что даёт 12 240 попыток в сутки.

Посмотрите на две правые колонки. Удвоение срока жизни пароля меняет требуемую длину на 0,22 символа. После округления не меняет вообще: девять символов в обоих случаях, восемь символов в обоих случаях.

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

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

Заодно снимем распространённое недоразумение: ни о каком «полном переборе за год» здесь речи нет. Полный перебор восьмисимвольного пароля из 36-символьного алфавита при 12 240 попытках в сутки занял бы порядка 630 тысяч лет. Расчёт идёт от вероятности 10⁻⁶ — пространство должно быть в миллион раз больше числа попыток, которые нарушитель успевает сделать за срок жизни пароля.

Итак: документ, которому приписывают происхождение плановой ротации, в своём единственном численном примере доказывает, что период смены — наименее значимый параметр модели.

3.4. Оговорка, которая всё меняет

Раздел C.2 называется «Guess Rate» и посвящён тому, от чего зависит R. Первым же пунктом там стоит защищённость базы паролей. Авторы разбирают три случая:

1. база паролей читается как обычные данные — тогда «угадывать» вообще не требуется;

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

3. база защищена механизмами доступа и процедуру входа нельзя обойти — тогда R ограничивается лимитами на число попыток.

Расчёт из C.6 выполнен исключительно для третьего случая. Про второй сказано, что темп подбора становится очень высоким, — и на этом всё, в модель он не заводится.

Оцените положение. Аргумент, ради которого плановую ротацию защищают сегодня — офлайн-перебор украденного хэша, — опирается на документ, который сам вынес этот случай за границы применимости своей формулы. Причём вынес корректно: как только база утекает, R перестаёт быть управляемым параметром защиты и вырастает на много порядков. Соотношение P = L·R/S формально продолжает работать, но при R, выросшем в миллиарды раз, никакой реалистичный L его не спасает — спасает только рост S, то есть длина пароля.

Ровно то же самое получается в разделе 5 на современных числах. Вывод был доступен уже в 1985 году.

3.5. Так откуда всё-таки 90 дней

Из «зелёной книги» — ниоткуда. Ни одна из шести величин её таблицы не даёт 90 дней. Рекомендация документа (п. 4.2.2.1) — максимальный срок жизни не более одного года, и обоснована она не расчётом, а отдельным соображением: защита от неизвестных угроз.

А в п. 4.2.2 названа и цель периодической смены: противодействие возможности необнаруженной компрометации пароля.

Это стоит осознать. Механизм, выведенный в разделе 5 перебором альтернатив, — единственный, ради которого ротация вообще существует, — назван в первоисточнике прямым текстом сорок лет назад. И назван как соображение, отдельное от расчёта: математика даёт год, а всё, что короче года, обосновывается уже не ею.

Цифра 90 закрепилась позже и другим путём — и здесь у истории появляется второй фигурант.

Вторым источником правила обычно называют NIST Special Publication 800-63, точнее её приложение A, написанное в 2003 году Биллом Бёрром — на тот момент менеджером среднего звена в Национальном институте стандартов и технологий США. Восемь страниц, содержание которых в пересказах прессы звучит так: пароль должен содержать заглавные буквы, цифры и спецсимволы, и его следует регулярно менять — не реже чем раз в 90 дней. Этого хватило. Документ стал шаблоном парольной политики для федеральных агентств, университетов и корпораций по всему миру — американская пресса позже назвала его сводом законов о паролях. Именно через него, а не через «зелёную книгу», требование дошло до настроек по умолчанию в корпоративных каталогах, а оттуда — до нас.

В августе 2017 года Бёрр дал интервью Wall Street Journal, в котором сказал, что о многом из написанного теперь жалеет. Фраза была общей, без разбора по пунктам, но пояснение он дал конкретное: сложные правила выводят людей из себя, и хороших паролей от этого не получается. И отдельно отметил, что в 2003 году эмпирических данных по стойкости паролей почти не было — рекомендации строились на общих соображениях. Запомним эту оговорку: к ней придётся вернуться.

К тому моменту NIST уже переписал документ. Ревизию под руководством Пола Грасси вели два года; в июне 2017 года вышла редакция, из которой убрали и требование спецсимволов, и обязательное истечение паролей, заменив последнее правилом менять пароль при признаках компрометации. Сам Грасси, к слову, счёл самокритику Бёрра чрезмерной: документ продержался в качестве отраслевого стандарта пятнадцать лет.

В действующей редакции — NIST SP 800-63B-4 (июль 2025 г.), п. 3.1.1.2 — формулировка предельно жёсткая: проверяющей стороне запрещено требовать периодической смены паролей, но она обязана принудительно сменить пароль при наличии свидетельств компрометации аутентификатора. Соседние пункты того же раздела запрещают и композиционные правила, и устанавливают минимальную длину в 15 символов для пароля как единственного фактора.

3.6. Проверка второго первоисточника

На этом можно было бы закончить, но документ Бёрра тоже стоит открыть. Я открыл — и требования, которое ему приписывают, там не нашёл.

В тексте SP 800-63 версии 1.0 сочетание «90 дней» не встречается ни разу. Слова «периодически» применительно к смене пароля — тоже. Обязательного истечения пароля документ не устанавливает вовсе.

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

Числа в разобранных примерах показывают, насколько редко.

Первый пример: пароль из шести символов, случайно выбранных из алфавита в 94 знака, — 39,5 бита энтропии. Блокировка на минуту после трёх неудачных попыток ограничивает автоматизированную атаку тремя попытками в минуту, и на исчерпание допустимого числа попыток уйдёт около 90 лет. Вывод авторов: при такой блокировке и смене пароля раз в десять лет требования уровня 2 выполняются с запасом.

Второй пример: восьмисимвольный пароль, выбранный самим пользователем при действующих композиционных и словарных правилах, — 30 бит энтропии. Блокировка на сутки после шести неудачных попыток даёт нарушителю 6 попыток в день, или 4380 попыток за два года. Вывод: смены раз в два года достаточно.

Девяносто лет на перебор, десять лет и два года — на срок жизни пароля. Никаких девяноста дней.

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

Расставим ответственность честно, потому что здесь легко переусердствовать.

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

А вот за девяностодневную ротацию Бёрр не извинялся — и не мог бы, поскольку не он её ввёл. Его фраза о сожалении была общей, без разбора по пунктам. Разбор сделала газета: в том же материале смена пароля раз в 90 дней была названа промахом наравне со спецсимволами, публикации разошлись по всему миру — и с тех пор цифру возводят к документу Бёрра. Возражать он не стал.

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

3.7. Где 90 дней появились на самом деле

Если ни один из двух «канонических» источников цифру не содержит, откуда она?

Из ведомственных инструкций и отраслевых стандартов — и там она возникает сразу в готовом виде, без расчёта и без ссылки на источник. Три документа, которые удалось проверить по первоисточникам: два старше документа Бёрра, третий вышел практически одновременно с ним.

Административная инструкция 26 Министерства обороны США (март 1999 г.), глава 11, раздел 5.1.1. Восемнадцать требований к идентификации и аутентификации, требование № 5: пароли должны меняться не реже чем раз в 90 дней. Обоснование отсутствует. Сам текст инструкции в открытом доступе мне найти не удалось — её содержание я привожу по аудиторскому отчёту генерального инспектора Министерства обороны (отчёт D-2000-058 от 20 декабря 1999 г.), где требования перечислены дословно.

И ценность этого отчёта даже выше, чем самой инструкции: он сравнил семь действовавших в ведомстве политик между собой. Результат: ВВС требовали смены раз в 90 дней, а DISA, Управление тыла, финансовая служба и Армия — раз в 180 дней; Армия отдельно оговаривала 90 дней только для секретных систем; политики Министерства обороны в целом и ВМС требования о смене паролей не содержали вовсе. Аудиторы констатировали: единых требований нет, каждое ведомство пишет своё.

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

NIST SP 800-26 (ноябрь 2001 г.), руководство по самооценке безопасности информационных систем. В опроснике по разделу аутентификации есть вопрос: меняются ли пароли не реже чем раз в 90 дней или чаще при необходимости. Формат документа — чек-лист для аудитора; обоснований он не предполагает по жанру.

PCI DSS версии 1.0 (15 декабря 2004 г.), требование 8.5.9: менять пароли пользователей не реже чем раз в 90 дней. Рядом — минимальная длина в семь символов, запрет на повтор четырёх последних паролей, блокировка после шести попыток на тридцать минут. Именно этот документ сделал цифру обязательной для всех, кто принимает платёжные карты, и через сферу платежей она разошлась по отраслям.

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

Это ровно тот механизм, о котором шла речь в разделе 1. Мера, возникшая из требования проверяемости, обосновывается задним числом — потому что изначального обоснования у неё не было.

3.8. Промежуточный итог

Сведём три линии.

Документы, которые считают, цифры 90 не дают. «Зелёная книга» выводит срок жизни из скорости подбора, рекомендует максимум год и своим же примером показывает, что период почти ни на что не влияет: удвоение срока меняет требуемую длину на четверть символа. Приложение A к SP 800-63 использует ту же схему и приходит к двум и десяти годам.

Документы, которые предписывают, не считают. Инструкция Министерства обороны 1999 года, опросник NIST 2001 года и PCI DSS 2004 года называют 90 дней без единого обоснования. Разброс в семь раз между политиками разных подразделений одного ведомства показывает, что цифру назначали.

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

И «автор» нормы её не писал. Билл Бёрр, которого пятнадцать лет называют отцом девяностодневной ротации, в своём документе её не устанавливал, а извинялся за композиционные правила. Авторство приписала пресса, и оно прижилось.

Мне ни разу не встречалась парольная политика с формулировкой «менять раз в 90 дней», сопровождаемая расчётом, из которого эти 90 дней получены. Теперь понятно, почему: такого расчёта не существует. Норма держится не на выводе, а на повторении — и это ровно тот механизм, по которому, как показали Habib с соавторами, люди усваивают советы по безопасности (раздел 7.1).

3.9. Что ещё есть в «зелёной книге»

Раз уж документ открыт, стоит отметить: отрасль унаследовала из этого документа ровно один пункт — периодическую смену — и потеряла остальное. А остальное такое:

• Пароли должны генерироваться машиной, а не человеком (п. 4.4.1, приложение A). Минимальная длина — 6 символов. Весь расчёт из приложения C верен только для случайных машинно-сгенерированных паролей. Для придуманных человеком он недействителен — что через двадцать пять лет и измерили Zhang с соавторами.

• Парольные фразы (C.7): трёх слов, выбранных случайно из словаря на 23 300 слов, достаточно для той же стойкости. Diceware появится примерно через десять лет.

• Пароли должны быть произносимыми и запоминаемыми (A.4). Никаких требований «обязательно спецсимвол и цифра» — эта идея возникнет позже и будет отменена NIST в 2017 году.

• Истечение пароля по числу неудачных попыток, а не по календарю (приложение E.2): например, пометить пароль истёкшим после 100 неудачных попыток и заблокировать идентификатор после 500. Риск-ориентированная смена — в 1985 году.

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

• Отдельная процедура при увольнении (п. 4.1.5): немедленное уведомление офицера безопасности об удалении учётной записи плюс ежегодная ревалидация всех идентификаторов. Строка 9 таблицы из раздела 4 закрывалась специальным контролем, а не ротацией.

• Идентификатор принадлежит одному человеку (п. 4.1.4): знание пароля двумя людьми объявлено нарушением безопасности. Строка 9 закрывалась ещё и запретом на разделяемые учётные записи.

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

3.10. Что из этого следует

Первое. Модель 1985 года была параметрической: срок зависел от скорости подбора и размера пространства. Практика превратила её в константу, оторванную от обоих параметров.

Второе. Единственная угроза, ради которой мера создавалась, — подбор пароля через процедуру входа при контролируемом темпе попыток. Ни фишинга в современном виде, ни стилеров, ни credential stuffing, ни угона сессионных токенов в модели не было и быть не могло. Офлайн-перебор был назван — и явно исключён из расчёта.

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

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

4. Прямой ход: конкретная учётная запись, конкретные угрозы

Сделаем то, что требует методология. Зафиксируем объект и построим модель угроз, а меры будем подбирать после.

Объект защиты. Учётная запись внутреннего непривилегированного пользователя в домене Windows. Информационная система класса защищённости К3, локальный доступ. По мере ИАФ.3 методического документа ФСТЭК России от 12 апреля 2026 г. в этом сценарии допускается простая (парольная) аутентификация: длина не менее 12 символов, алфавит не менее 70 символов, блокировка после 5 неуспешных попыток на 15 минут, смена пароля не более чем через 90 дней.

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

Перечислим угрозы получения доступа к учётной записи и для каждой посмотрим, что её нейтрализует. Техники обозначены по MITRE ATT&CK для однозначности.

Результат прямого хода: из десяти угроз плановая ротация значима в двух (7 и 9), даёт узкий эффект в одной (6), в двух (4 и 10) работает против защищённости и в остальных не влияет.

Угроза под меру здесь не подбиралась: перечислены угрозы и показано, что мера делает с каждой. Картина получилась другой, чем при обратном ходе.

Обратите внимание и на другое. Строки 7 и 9, где ротация работает, — это не «пароль подобрали». Это компрометация без утечки в чистом виде: секрет никуда не утекал, но доверять ему больше нельзя. Различение из раздела 2 здесь работает буквально.

5. Единственный механизм и полоса его действия

Обобщим таблицу. За счёт чего плановая смена может повышать защищённость?

Механизм ровно один: ротация ограничивает срок полезности учётных данных, компрометация которых не обнаружена. Строки 6, 7 и 9 — три его частных случая: скомпрометированный хэш, скомпрометированный производный секрет, скомпрометированное знание.

Это тот же механизм, который назван в п. 4.2.2 «зелёной книги»: периодическая смена нужна, чтобы противодействовать возможности необнаруженной компрометации. За сорок лет список альтернатив не пополнился.

Насколько узок получаемый выигрыш? Перейдём к соотношению величин.

Обозначим:

• T_взлом — время восстановления пароля из украденного хэша;

• T_ротация — период плановой смены;

• T_обнаружение — время до обнаружения компрометации.

Ротация даёт эффект при одновременном выполнении трёх условий:

1. T_ротация < T_взлом — иначе атакующий успевает раньше;

2. T_взлом конечно и практически достижимо — иначе атака не удастся и без ротации;

3. T_обнаружение > T_ротация — иначе сработает целевая смена по инциденту, и плановая ни при чём.

Третье условие — это ровно развилка из раздела 2, записанная формально: плановая ротация приносит пользу только там, где наблюдение не отработало.

Условия 1 и 2 задают полосу: T_ротация < T_взлом < T_ценность, где последнее — срок, в течение которого доступ вообще представляет интерес.

Насколько она широка? Возьмём модель из предыдущей статьи — bcrypt cost 10, кластер из 16 RTX 5090, измеренные 138 675 H/s.

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

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

И это условие выполняется требованиями тех же самых документов, которые ротацию предписывают. Мера ИАФ.3 требует 12 символов при алфавите 70 — пространство 70^12 ≈ 1,4·10^22, в приведённой модели порядка трёх миллиардов лет перебора. «Рекомендации по устранению типовых ошибок конфигурации (настройки) общесистемного и прикладного программного обеспечения» ФСТЭК России 2026 года в п. 1.1 рекомендуют минимальную длину пароля не менее 15 символов — и в той же таблице максимальный срок действия 60–90 дней.

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

6. Аргументы «за» в самой сильной формулировке

Изложу позицию сторонников ротации так, как её стоит излагать.

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

Аргумент 2. Дедлайн для офлайн-перебора. Контраргумент «атакующий не сможет продолжить перебор с места остановки» бьёт мимо: атакующий работает со снимком — хэшем на момент утечки, и смена пароля в системе на снимок не влияет. Но ротация ставит атакующему дедлайн: результат, полученный после смены, обесценивается.

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

Аргумент 4. Дисциплинированному пользователю ротация не вредит. Если человек строит пароли по устойчивому мысленному алгоритму, не выводимому извне, регулярная смена стойкости не снижает. Значит, деградация — свойство лени, а не меры.

Аргумент 5. «Неудобно» — не аргумент безопасности. Мыть руки тоже неудобно.

Аргумент 2 корректен внутри полосы из раздела 5 и там же ограничен. Разберём остальные.

7. Разбор

7.1. Ротация не повышает стойкость паролей — и обнуляет её там, где нужна

Здесь есть измеренные данные, и они говорят не совсем то, что обычно пересказывают. Разберу подробно, потому что именно на этом месте статью легче всего поймать на том самом cherry picking, в котором раздел 1 упрекает оппонентов.

Zhang, Monrose, Reiter (ACM CCS 2010), The Security of Modern Password Expiration. Авторы получили истории паролей 7752 университетских учётных записей — реальные последовательности «старый пароль → новый пароль» — и построили алгоритм предсказания следующего пароля по предыдущему. Около 17 % новых паролей угадывались в пределах пяти онлайн-попыток при знании старого; около 41 % восстанавливались за секунды офлайн-анализа.

Chiasson, van Oorschot (Designs, Codes and Cryptography, 2015), Quantifying the security advantage of password expiration policies. Авторы прямо ставят задачу количественно оценить выигрыш от истечения паролей, отмечая, что до них он декларировался, но не измерялся. <cite index=»26-1″>Полученный оптимальный выигрыш они характеризуют как в лучшем случае незначительный и сомнительный с учётом общих издержек.</cite>

Habib и др. (USENIX SOUPS 2018), User behaviors and attitudes under password expiration policies. Два опроса о том, как люди живут с политикой истечения. Сразу оговорю метод: это самоотчёты респондентов, а не измеренные истории паролей, как у Zhang, — данные слабее, зато охват организаций шире. Результаты неоднозначны, и в этом их ценность.

Что подтвердилось: стратегии адаптации предсказуемы. Большинство участников при смене применяют простую модификацию текущего пароля; полностью новый пароль придумывает менее четверти.

Что не подтвердилось: авторы не нашли свидетельств, что эти стратегии ведут к более слабым паролям. Более частая смена не увеличила повторное использование паролей с других аккаунтов. Не выросли ни число блокировок учётных записей, ни заявленный уровень раздражения.

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

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

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

NCSC (2016), The problems with forcing regular password expiry. Британский регулятор публично отказался от рекомендации регулярной смены, указав, что она создаёт больше проблем, чем решает.

Cranor (FTC, 2016), Time to rethink mandatory password changes. Главный технолог Федеральной торговой комиссии США обобщила данные Zhang и Chiasson с рекомендацией пересмотреть обязательную смену.

Microsoft (2019). Компания исключила требование срока действия пароля из базовой конфигурации безопасности Windows 10 v1903, охарактеризовав его как устаревшую меру очень низкой ценности.

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

Теперь сведём Zhang и Habib вместе — вместе они дают более точное утверждение, чем каждое по отдельности.

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

Но она и не растёт. Ротация не заставляет людей выбирать пароли лучше — а именно этим её нередко оправдывают («будут придумывать что-то посерьёзнее»).

А условная стойкость — при известном старом пароле — рушится. Zhang измерил это на реальных историях: 41 % за секунды.

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

Это сильнее исходного тезиса и при этом строго соответствует данным: спорить приходится не о том, вредна ротация или нет, а о том, что она не работает там, где должна.

Отсюда и ответ на аргумент 4. Да, для человека с устойчивой персональной схемой ротация безвредна. Но парольная политика — системная мера, а не индивидуальная рекомендация; оценивается она по среднему эффекту на популяции. Мера, безвредная для меньшинства и ухудшающая ситуацию для большинства, в сумме отрицательна.

7.2. Окно реакции атакующего короче периода ротации на порядки

Аргумент о сокращении окна неявно предполагает медлительного атакующего. Отраслевые данные говорят иначе.

CrowdStrike Global Threat Report 2026. Средний breakout time — время от первичного проникновения до перемещения на соседние системы — составил в 2025 году 29 минут, что на 65 % быстрее прошлогоднего показателя. Рекорд года — 27 секунд. Отдельно отмечено, что 82 % зафиксированных атак обошлись вообще без вредоносного ПО: злоумышленники работают руками, через легитимные инструменты и действующие учётные данные. Более чем в трети расследований облачных инцидентов причиной доступа оказались действительные или скомпрометированные учётные данные.

Двадцать девять минут против девяноста дней. Разница в четыре с половиной тысячи раз.

Verizon 2026 Data Breach Investigations Report. Здесь картина сложнее, и её лучше передать словами самого отчёта. <cite index=»0-1″>»Exploitation of vulnerabilities is now the most common initial access vector for breaches.»</cite> Показатель вырос до 31 % против 20 % годом ранее, а злоупотребление учётными данными как первое зафиксированное действие опустилось до 13 %. Но авторы тут же предупреждают против поспешного вывода: <cite index=»0-2″>»if you consider all instances of credential abuse at any point in the breach progression, it still sits on top at 39%.»</cite>

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

Теперь про контрдовод, который есть в том же отчёте.

Обойти его было бы нечестно, а он серьёзный. Исследователи Verizon сопоставили жертв программ-вымогателей с предшествовавшими утечками учётных данных и заражениями стилерами. У 27 % жертв за предшествующий год ничего подобного не нашлось. А у остальных — <cite index=»0-3″>»50% of those ransomware victims had a credential or infostealer event occur within 95 days prior to falling victim to a ransomware attack.»</cite>

Медиана в 95 дней — это почти в точности период ротации. Формально смена пароля раз в 90 дней обесценила бы примерно половину таких учётных данных до того, как ими воспользовались. Это самый сильный эмпирический довод в пользу плановой ротации, который мне известен, и статья была бы нечестной, если бы его не привела.

Три уточнения, которые его ослабляют.

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

По данным M-Trends 2026 (Mandiant, более 500 тысяч часов расследований за 2025 год), глобальная медиана времени скрытого присутствия составила 14 дней. Российская картина хуже: по данным BI.ZONE DFIR, среднее время присутствия злоумышленника в инфраструктуре российских компаний выросло с 25 дней в 2024 году до 42 дней в 2025-м, а минимальное время от проникновения до начала шифрования составило 12,5 минуты.

Вычтем. Из 95 дней от компрометации учётных данных до публикации 42 дня приходятся на присутствие атакующего внутри — и это не считая срока от шифрования до публикации, который обычно составляет ещё дни или недели. Остаётся порядка 40–50 дней между появлением учётных данных в утечке и входом в систему.

Это меняет вывод: против интервала в 40–50 дней смена пароля раз в 90 дней срабатывает заметно реже, чем в половине случаев. Точнее сказать нельзя — величины взяты из разных исследований, считаны по разным выборкам и описывают разные события, так что это оценка порядка, а не расчёт. Но направление поправки однозначно, и работает она против ротации. К тому же смена с фиксированным периодом ловит компрометацию случайно: момент смены никак не привязан к моменту утечки.

Второе. Это со-встречаемость, а не установленная причинность: наличие утечки перед атакой не означает, что вошли именно по ней.

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

То есть наблюдение Verizon — довод в пользу мониторинга утечек, а не календаря. Ровно тот вывод, к которому пришёл раздел 2.

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

Здесь же уместно вспомнить The Tangled Web of Password Reuse (Das и др., NDSS 2014): авторы показали масштаб повторного использования паролей и, что важнее, предсказуемость их модификаций между сервисами. Ваша ротация не влияет на значение, которое пользователь применил ещё на десяти сайтах.

7.3. Инвалидация сессий — подмена задачи

Аргумент 3 верен фактически, но неверен методологически. Завершение сессий — функция управления сессиями, а не свойство парольной политики.

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

Показательно, что и методический документ ФСТЭК разводит эти задачи: управление сессиями вынесено в отдельные меры и не выводится из парольной политики.

7.4. Незнание о компрометации лечится наблюдением, а не календарём

Аргумент 1 — самый сильный, и он указывает на реальный пробел. Но, как показано в разделе 2, он подменяет компрометацию утечкой, а лечение не соответствует диагнозу.

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

Замечу, что в российских требованиях это уже зафиксировано, и довольно прямо. «Рекомендации по устранению типовых ошибок конфигурации (настройки) общесистемного и прикладного программного обеспечения» ФСТЭК России 2026 года в п. 1 предписывают не только парольную политику, но и:

• регулярную проверку паролей на известные утечки — с прямым упоминанием HaveIBeenPwned API (п. 1.4);

• регулярную проверку паролей на соответствие парольным словарям (п. 1.5);

• двухфакторную аутентификацию для привилегированных пользователей (п. 1.3);

• запрет повторного использования паролей через ведение журнала (п. 1.2).

То есть регулятор требует ровно тех мер, которые закрывают строки 3 и 4 таблицы из раздела 4 и которых плановая ротация не закрывает. Аргумент «у нас нет способа узнать о компрометации» не является ни технически, ни нормативно приемлемым.

7.5. Про «неудобство»

Аргумент 5 формально корректен: тягость сама по себе меру не отменяет. Но важна не тягость, а её последствия для модели угроз.

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

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

Данные Habib здесь довольно неожиданны: при более частой смене люди не жалуются сильнее и не блокируют учётные записи чаще — они просто адаптируются. То есть спор о тягости ротации можно закрывать с обеих сторон. Издержки для пользователя невелики; проблема не в них, а в том, во что превращается сам пароль.

8. Угрозы, порождаемые самой ротацией

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

Password spraying по сезонным шаблонам (T1110.003). Атака перебирает не пространство паролей, а небольшой список наиболее вероятных значений против множества учётных записей — так она обходит блокировку по числу попыток. Список кандидатов состоит преимущественно из конструкций вида «Сезон + Год + !», «Месяц + Год», «Название компании + Год». Эти шаблоны существуют ровно потому, что пользователю нужно каждые 90 дней придумывать «новый» пароль, привязанный к моменту времени. Мера не просто не защищает от spraying — она производит для него словарь.

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

Сентябрь 2023 года, Caesars Entertainment. В отчёте по форме 8-K, поданном в Комиссию по ценным бумагам и биржам США, компания указывает источник инцидента прямым текстом: атака методами социальной инженерии на внешнего подрядчика ИТ-поддержки. Итог — злоумышленник получил копию базы программы лояльности с номерами водительских удостоверений и социального страхования участников. Никакого перебора паролей: сотрудника службы поддержки убедили голосом.

Тогда же была атакована MGM Resorts. Собственный отчёт компании по форме 8-K вектор не раскрывает, но фиксирует масштаб: отрицательное влияние на показатель Adjusted Property EBITDAR — около 100 млн долларов, плюс менее 10 млн разовых расходов; злоумышленники получили персональные данные клиентов, включая номера водительских удостоверений, а у части — номера социального страхования и паспортов. Вектор известен по публичным разборам: группе Scattered Spider хватило телефонного звонка в службу поддержки и данных из открытых источников, чтобы за десять минут получить критичные учётные данные, а затем добиться и сброса факторов многофакторной аутентификации.

Чем плотнее поток обращений на сброс пароля, тем дешевле в нём замаскироваться. Ротация этот поток и создаёт.

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

И ещё одно наблюдение, которое стоит того, чтобы завершить им раздел. M-Trends 2026 фиксирует: атакующие эксплуатируют неверно настроенные шаблоны служб сертификации Active Directory, чтобы создавать административные учётные записи, обходящие ротацию паролей. Мера не просто не мешает — она стала настолько предсказуемым элементом ландшафта, что противник проектирует закрепление с учётом её обхода. Смена пароля наступит и ничего не изменит.

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

9. Где плановая ротация оправдана

Полный отказ — такая же некритичная позиция, как и тотальное применение. Вернёмся к строкам 7 и 9 таблицы из раздела 4 и обобщим.

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

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

3. Производные секреты, переживающие пароль. Строка 7 таблицы: NT-хэш, пригодный для Pass-the-Hash, действителен, пока действителен пароль. Здесь смена работает — но как компенсирующая мера при отсутствии Credential Guard и сегментации.

4. Первый вход и временные пароли. Пароль, выданный администратором, меняется немедленно. Это не плановая ротация, а устранение известной компрометации: секрет заведомо знает ещё один человек.

Общий признак: ротация оправдана там, где секрет заведомо известен более чем одной стороне или где её выполняет не человек. И заметьте — это в точности случаи компрометации без утечки из раздела 2.

10. Что делать на практике

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

1. Перейти на усиленную аутентификацию везде, где это допускается. Это снимает вопрос о ротации по существу, а не по форме: PCI DSS v4.0 прямо освобождает от 90-дневной смены учётные записи с MFA.

2. Выдать пользователям менеджер паролей (при необходимости отечественный — п. 6.2 Рекомендаций ФСТЭК прямо предлагает такой вариант). Это единственный способ сделать ротацию нейтральной: генератор не изобретает предсказуемых преобразований. Ровно к этому пришли и Habib с соавторами: политика истечения приносит пользу главным образом при достаточно случайных паролях, а сами люди их не создают. И проверьте, не запрещены ли у вас менеджеры паролей одновременно с введённым истечением — такое сочетание встречается часто и обнуляет всю конструкцию.

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

4. Внедрить регулярную проверку на утечки и словари — это уже прямое требование п. 1.4–1.5 Рекомендаций, а не инициатива.

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

6. Ужесточить процедуру верификации при сбросе пароля через службу поддержки — раз уж ротация генерирует поток обращений.

7. Отработать процедуру целевой смены по компрометации — с явным перечнем событий, при которых она запускается (увольнение, инцидент на АРМ, срабатывание средства защиты, обнаружение учётных данных в утечке). Это то, чего плановая ротация не заменяет.

8. Автоматизировать ротацию сервисных учётных записей через управление секретами, а не через регламент и человека.

Пункты 2, 5 и 6 существенны. Плановая ротация вредна не сама по себе, а в связке с человеком, придумывающим пароль. Разорвите связку — и требование перестанет ухудшать защищённость.

11. Выводы

Цифра 90 дней не выведена ниоткуда. В документах, которые считают («зелёная книга» 1985 г., приложение A к SP 800-63), получаются год, два года и десять лет. В документах, которые предписывают (инструкция Министерства обороны США 1999 г., опросник NIST 2001 г., PCI DSS 2004 г.), стоят 90 дней без расчёта. Разброс от 90 до 180 дней между политиками подразделений одного ведомства показывает, что величину назначали. Даже общепризнанное авторство нормы оказалось приписанным: Билл Бёрр девяностодневную смену не вводил и извинялся не за неё.

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

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

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

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

Мера отказывает в том сценарии, ради которого введена. Ротация оправдывается необнаруженной компрометацией, то есть случаем, когда старый пароль уже у злоумышленника, — но именно тогда новый пароль предсказуем: 41 % восстанавливается за секунды при известном предыдущем (Zhang и др., 2010). При этом стойкость паролей от ротации и не растёт (Habib и др., 2018), а аналитическая оценка выигрыша даёт в лучшем случае незначительную величину (Chiasson, van Oorschot, 2015).

Мера порождает собственные угрозы: словарь для password spraying, поток обращений в службу поддержки как вектор социальной инженерии, материализацию секрета на бумаге. В обосновании они не учитываются — прямое следствие обратной логики.

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

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

Источники

Исследования

1. Zhang Y., Monrose F., Reiter M. K. The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis. ACM CCS, 2010.

2. Chiasson S., van Oorschot P. C. Quantifying the security advantage of password expiration policies. Designs, Codes and Cryptography, 77(2–3), 2015, с. 401–408.

3. Habib H., Emami-Naeini P., Devlin S., Oates M., Swoopes C., Bauer L., Christin N., Cranor L. F. User Behaviors and Attitudes Under Password Expiration Policies. USENIX SOUPS, 2018.

4. Das A., Bonneau J., Caesar M., Borisov N., Wang X. The Tangled Web of Password Reuse. NDSS, 2014.

5. Verizon. 2026 Data Breach Investigations Report. verizon.com/dbir

6. CrowdStrike. Global Threat Report 2026.

7. Mandiant (Google Cloud). M-Trends 2026, март 2026 г.

8. BI.ZONE DFIR, BI.ZONE Compromise Assessment. От выявления компрометации до реагирования: как российские компании справлялись с кибератаками в 2025 году.

9. Corey Neskey. Are Your Passwords in the Green? Hive Systems, 2026.

Стандарты и руководства

10. NIST. SP 800-63B-4: Digital Identity Guidelines. Authentication and Authenticator Management, июль 2025 г. П. 3.1.1.2.

11. Department of Defense Computer Security Center. CSC-STD-002-85, Password Management Guideline, 12 April 1985. Приложения A, C, E, F.

12. NIST. Special Publication 800-63 v1.0, Electronic Authentication Guideline, Appendix A (Burr W.), 2003 — исторический документ, отменён редакцией 2017 года.

13. McMillan R. The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d! The Wall Street Journal, 7 августа 2017 г.

14. Office of the Secretary of Defense. Administrative Instruction 26, Chapter 11, Section 5.1.1, March 1999 (изложено в: Inspector General, DoD. Identification and Authentication Policy, Report No. D-2000-058, 20 December 1999).

15. NIST. Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems, November 2001 (документ отменён).

16. Visa U.S.A. Payment Card Industry Data Security Standard, Version 1.0, 15 December 2004, требование 8.5.9.

17. PCI Security Standards Council. PCI DSS v4.0, требование 8.3.9.

18. NCSC. The problems with forcing regular password expiry, 2016.

19. Cranor L. Time to rethink mandatory password changes. FTC, 2016.

20. Microsoft. Security baseline for Windows 10 v1903 — обоснование отказа от password expiration, 2019.

Российские нормативные и методические документы

21. Приказ ФСТЭК России от 11 апреля 2025 г. № 117.

22. Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах». Утверждён ФСТЭК России 12 апреля 2026 г. Мера ИАФ.3.

23. Рекомендации по устранению типовых ошибок конфигурации (настройки) общесистемного и прикладного программного обеспечения. ФСТЭК России, 2026. Пп. 1.1–1.5, 6.1–6.2.

24. Методика оценки угроз безопасности информации. Утверждена ФСТЭК России 5 февраля 2021 г.

25. ГОСТ Р 50922-2006. Защита информации. Основные термины и определения.

26. Приказ ФАПСИ от 13 июня 2001 г. № 152.

Прочее

27. Caesars Entertainment, Inc. Form 8-K, Item 8.01. U.S. Securities and Exchange Commission, 14 сентября 2023 г.

28. MGM Resorts International. Form 8-K, Items 2.02 и 7.01. U.S. Securities and Exchange Commission, 5 октября 2023 г.

29. Bisceglia N. MGM Resort Cyberattack. TeamPassword, 2025.

30. MITRE ATT&CK: T1003, T1056, T1078, T1110, T1539, T1550.002, T1555, T1566.

31. Иван Земцов. Какие должны быть пароли в 2026 году. Хабр, 2026.