Почему совет менять пароли каждые 90 дней устарел

MAATRIX

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

Откуда взялось правило «90 дней»

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

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

Как реально ведут себя люди при принудительной смене

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

Типичные паттерны трансформации выглядят так:

• Summer2025! → Summer2026! — смена цифры года на следующий
• password1 → password2 → password3 — инкремент числа в конце
• Ivanov_qwerty → Ivanov_qwerty1 — добавление символа в конец без изменения основы
• Serverok2025 → Serverok2025! → Serverok2026! — минимальные косметические правки

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

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

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

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

• Утечка базы данных сервиса. Если пароль (или его хеш) оказывается в дампе взломанной базы, атакующий не будет ждать три месяца — автоматизированные инструменты credential stuffing проверяют утёкшую пару логин/пароль против тысяч других сервисов в течение часов после публикации дампа, пока учётные данные ещё «свежие» и совпадают с реальными действующими паролями пользователей.
• Фишинг. Пароль, введённый на поддельной странице входа, доступен атакующему сразу же — ротация через 90 дней в этом сценарии просто оставляет три месяца окно, в течение которого скомпрометированный пароль остаётся рабочим, вместо того чтобы закрыть доступ немедленно после обнаружения.
• Кейлоггер или инфостилер на клиентской машине. Вредонос, ворующий пароли из браузера или перехватывающий нажатия клавиш, передаёт их атакующему в реальном времени. Периодичность смены пароля никак не влияет на скорость, с которой ворованные данные попадают в оборот.
• Повторное использование пароля между сервисами. Если пароль от корпоративной системы совпадает (или почти совпадает) с паролем от давно взломанного форума, утечка на стороне форума становится утечкой корпоративного доступа — независимо от того, когда в последний раз меняли пароль внутри компании.

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

Куда сдвинулись современные рекомендации

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

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

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

Как настроить это на практике

Для читателя, который управляет собственными серверами, а не только корпоративными аккаунтами в SaaS-сервисах, смещение фокуса выглядит так:

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

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

chage -l имя_пользователя

Вывод покажет Password expires и Maximum number of days between password change. Отключить принудительное истечение для конкретного системного аккаунта (там, где вместо ротации по календарю уместнее контроль по событию):

chage -M 99999 имя_пользователя

Глобальная настройка политики по умолчанию для новых пользователей — в /etc/login.defs:

# было
PASS_MAX_DAYS   90
# разумная альтернатива для большинства некритичных аккаунтов —
# длинный интервал вместо частого, плюс отдельный процесс
# немедленной смены при инциденте
PASS_MAX_DAYS   365
PASS_MIN_LEN    12

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

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

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

Когда периодическая смена пароля всё-таки оправдана

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

• После подтверждённой компрометации. Если пароль или хеш засветился в утечке, если есть признаки несанкционированного доступа, если сотрудник, знавший пароль от общей учётной записи, уволился — пароль нужно менять немедленно, не дожидаясь конца квартала. Это тот самый триггер по событию, о котором говорят современные рекомендации.
• Для общих (shared) учётных записей. Если пароль от одной учётной записи знают несколько человек — например, общий аккаунт админ-панели или root-доступ на сервер, которым пользуется команда — периодическая смена компенсирует то, что вы физически не можете контролировать, у скольких людей на самом деле остался доступ к текущему значению. Здесь ротация не защищает от перебора, а ограничивает окно действия для людей, которые формально уже не должны иметь доступ.
• Для секретов с ограниченным сроком жизни по дизайну. API-ключи, токены доступа к внешним интеграциям, временные учётные данные для подрядчиков — такие секреты разумно ротировать планово именно потому, что их модель угроз другая: они часто копируются в конфиги, переменные окружения, CI/CD-пайплайны, и плановая замена снижает риск того, что забытая копия где-то в старом скрипте остаётся рабочей годами.
• Когда сам сервис требует этого по регуляторным причинам. Если аудит или отраслевой стандарт, под который подпадает конкретный проект, явно требует определённой периодичности смены — соблюдение требования может быть обязательным независимо от вашей личной оценки его эффективности. В этом случае разумно выполнять формальное требование, но не полагаться на него как на единственный слой защиты.

Во всех этих случаях частота смены определяется конкретным риском или конкретным правилом, а не универсальным «раз в 90 дней для всего подряд».

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