Парольная политика

1. Утверждение

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

2. Какую управляемость сохраняет

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

3. Механизм действия

Атаки на пароли делятся на три механики, и политика влияет на них по-разному:

• Перебор по словарям и утечкам (credential stuffing, spraying). Противник пробует известные пароли — из утечек этого же пользователя или самые популярные пароли против многих пользователей. Работают блок-листы и запрет повторного использования: они выбивают именно те пароли, которые противник попробует первыми.
• Офлайн-подбор по украденным хэшам. Решает длина (экспоненциальный рост стоимости подбора) и стойкое хэширование на стороне системы. Требования к составу почти не помогают: пользователи выполняют их шаблонно («Password1!»), и шаблоны давно встроены в инструменты подбора.
• Предсказание по прошлым паролям. Принудительная ротация заставляет пользователей порождать новый пароль из старого предсказуемой трансформацией (инкремент цифры, сезон+год). Противник, знающий старый пароль, восстанавливает новый с высокой вероятностью — мера работает против защищающегося.

Ключевая причинная модель: политика эффективна настолько, насколько она увеличивает фактическую непредсказуемость пароля для противника, а не формальную сложность для аудитора. Требования, которые пользователь выполняет шаблонно, дают формальную сложность без непредсказуемости.

4. Доказательная база

Критика источников. Это одна из немногих тем ИБ с настоящими контролируемыми экспериментами (школа CMU), но эксперименты лабораторные: участники создают пароли для исследования, а не для своей зарплатной учётки — внешняя валидность ограничена. Полевое исследование UNC (2010) — самое сильное доказательство против ротации, но оно одно и проведено в академической среде. Консенсус NIST/NCSC/Microsoft опирается на эту базу и взаимно согласован, что повышает доверие, но не заменяет репликаций.

5. Размер эффекта

• Вред ротации: при известном старом пароле ~41% новых паролей восстанавливаются офлайн почти мгновенно, ~17% — за ≤5 онлайн-попыток (UNC 2010). Положительный эффект ротации в полевых данных не зафиксирован.
• Композиционные правила: прирост фактической стойкости мал и съедается шаблонностью; количественно — единицы бит энтропии при заметном росте ошибок входа и обращений в поддержку (серия CMU).
• Блок-листы: выбивают пароли, на которые приходится непропорциональная доля успехов spraying-атак; точный полевой размер эффекта не опубликован — оценка уровня C, механизм прямой.
• Длина: каждый дополнительный символ умножает стоимость офлайн-подбора; против онлайн-атак при работающем троттлинге длина сверх разумного минимума даёт мало.
• Переиспользование: ~половина пользователей переносит пароли между сервисами — любая чужая утечка становится вашей атакой (Das 2014).

6. Границы применимости

Защищает (правильная политика):

• от password spraying и credential stuffing (блок-листы, проверка по утечкам, троттлинг);
• от офлайн-подбора при краже хэшей (длина + стойкое хэширование);
• от целевого угадывания по старым паролям (отказ от ротации устраняет сам паттерн «старый пароль + 1»).

Не защищает:

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

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

7. Известные способы обхода

8. Условия эффективности

1. Минимальная длина (для людей — от 12–14 символов или парольные фразы; для сервисных учётных записей — от 25+, поскольку их не вводят руками).
2. Блок-лист: топ популярных паролей, словари, контекстные слова (название организации, продукта, год) и проверка по базам утечек.
3. Отказ от плановой ротации; смена пароля — по событию: признаки компрометации, утечка, уход сотрудника с общих учёток.
4. Отказ от композиционных правил в пользу проверки фактической стойкости при создании.
5. Троттлинг и блокировка распылённых атак на стороне системы (включая защиту от spraying по многим учёткам, а не только подряд по одной).
6. Стойкое хэширование (bcrypt/scrypt/Argon2) — политика бессмысленна, если хэши падают за вечер.
7. Корпоративный менеджер паролей — единственный реалистичный способ добиться уникальных паролей без переиспользования.
8. MFA поверх — см. границы применимости.

9. Как проверить у себя

• Аудит собственных хэшей (санкционированный): выгрузка из AD и подбор современным инструментарием на типовом GPU-стенде. Метрика: доля паролей, восстановленных за 24 часа. Это самый честный показатель фактической, а не бумажной стойкости.
• Доля учётных записей с паролями из базы утечек (проверка через k-anonymity-сервисы или локальные базы).
• Симуляция password spraying по согласованному сценарию: срабатывает ли детектирование и блокировка.
• Проверка сервисных учётных записей: длина, возраст, наличие SPN с подбираемыми паролями.
• Статистика поддержки: число сбросов паролей до и после отмены ротации (ожидаемо падает — это измеримая выгода).

10. Что опровергло бы это утверждение

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

11. Стоимость владения

• Технически мера дешёвая: блок-листы и проверка стойкости — функции IdP/AD (включая бесплатные решения), троттлинг — конфигурация.
• Основная статья — корпоративный менеджер паролей (лицензии + внедрение + обучение).
• Отмена ротации снижает затраты: меньше сбросов через поддержку, меньше заблокированных учёток — редкий случай, когда доказательная мера экономит деньги.
• Скрытая и главная стоимость — комплаенс-конфликт. Ряд российских нормативных и методических документов и устоявшаяся практика аудиторов по-прежнему предполагают периодическую смену паролей и композиционные требования. Организация может быть вынуждена сохранять ротацию формально. Честная стратегия: выполнять обязательный минимум там, где он юридически неизбежен, фиксировать расхождение с доказательной базой в своей модели угроз и не распространять устаревшие требования шире зоны действия норматива. Это расхождение — само по себе материал для раздела «Критика моделей и практик».

12. Типичные ошибки внедрения

1. Ротация каждые 90 дней «потому что так было всегда» — при отсутствии блок-листов.
2. Композиционные правила без проверки по словарям: «P@ssw0rd2026!» проходит политику.
3. Политика только для людей: сервисные учётные записи с паролями десятилетней давности.
4. Нет защиты от spraying: блокировка после N ошибок по одной учётке, но 2 попытки на каждую из 10 000 учёток проходят незамеченными.
5. Слабое хэширование в унаследованных системах (NTLM без защиты, MD5/SHA-1 в самописных приложениях).
6. Запрет менеджеров паролей «из соображений безопасности» — прямое принуждение к переиспользованию.
7. Подсказки и контрольные вопросы как канал восстановления — секрет слабее самого пароля.

13. Связанные меры и связки

Парольная политика — нога той же связки «контроль доступа к ролям», что и MFA: пароль + второй фактор + защита сессий + защищённое восстановление. Самостоятельной ценности почти не имеет: её потолок — атаки на угадываемость, которые без неё дешевле всего, но с ней противник просто переходит к фишингу и краже. Поэтому статус меры — гигиенический минимум, а не самостоятельная защита. Смежные карты: MFA (SEC-CTRL-0001), условный доступ (SEC-CTRL-0003), защита сессий (SEC-CTRL-0004), менеджеры паролей (отдельная карта в планах).

14. История пересмотров