Парольные политики Windows: почему «пусть сами придумают» не работает

На прошлой неделе делали аудит в одной конторе - сеть на Windows 2000, Active Directory, сотрудников за пятьдесят. Клиент жаловался, что что-то медленно работает и вообще «что-то не так». Конкретики - ноль. Ладно, будем смотреть.

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

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

Что нашли

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

• Пустые пароли. Несколько штук. Прямо без пароля совсем. У одной из них - права локального администратора на паре машин. У кого-то при настройке просто не заполнили поле, и система не возразила.
• Пароли в один символ. «1», «q», «a» - три из этих вариантов встретились. Видимо, человека раздражало требование «хоть что-то введи», и он нажал одну кнопку.
• Логин равен паролю. Ivanov/ivanov, petrov/petrov. Классика. Каждый раз как первый.
• Словарные слова. «leto», «rabota», «admin». Сюда же «password» в русской транслитерации.

Отдельно нашлась учётка бухгалтера с паролем «1» и правами на сетевую папку с документами всей организации. Это не анекдот - это рабочий день.

Почему так вышло

Администратор развёл руками: «Ну я же объяснял, что нужно нормальные пароли ставить». Объяснял. Не помогло. И не помогло бы никогда, потому что это не работает.

Человек выбирает пароль из двух соображений: чтобы не забыть и чтобы поскорее закончить. Требования безопасности - абстракция, а усилие ввести нормальный пароль - конкретная трата времени прямо сейчас. Побеждает конкретика.

Никакие инструктажи и объяснения это не исправят. Вообще никакие. Единственное, что работает, - это когда система физически не принимает плохой пароль. Люди будут ругаться, но введут нормальный, потому что деваться некуда.

Что настроили

В Active Directory это делается через групповые политики. Мы уже разбирали, как они устроены, поэтому долго объяснять не буду - там всё через стандартный редактор политик.

Открыли Default Domain Policy и в разделе Account Policies / Password Policy выставили:

• Минимальная длина пароля - 7 символов. Меньше не имеет смысла при словарном переборе.
• Максимальный срок действия - 90 дней. Потом обязателен новый пароль.
• Минимальный срок действия - 1 день. Это затычка против тех, кто будет менять пароль десять раз подряд, чтобы вернуться к старому.
• История паролей - 5 последних. Повторять нельзя.
• Сложность обязательна - включили. Это встроенная проверка Windows: пароль должен содержать буквы разного регистра или цифры, и не должен совпадать с именем учётки.

Отдельно в разделе Account Lockout Policy:

• Блокировка после 5 неудачных попыток. После этого учётка блокируется на 30 минут. Автоматически разблокируется - чтобы не звонили администратору из-за каждого кривого ввода.

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

Что было дальше

Дальше было два дня звонков. Люди не понимали, почему их пароль вдруг не принимается, забывали новый, путались. Один сотрудник заблокировал себя три раза подряд, пытаясь вспомнить, что придумал. Администратор был занят - он раньше этим не занимался почти.

Это нормально. Первая неделя после внедрения политики всегда такая. Потом народ привыкает, и поток звонков спадает. Мы предупредили клиента заранее, он морально подготовился.

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

Насчёт пустых паролей отдельно

Пустой пароль в Windows 2000 по умолчанию разрешён для локальных учёток. Это не баг и не ошибка настройки - это поведение по умолчанию. Чтобы запретить вход с пустым паролем по сети, есть отдельная политика безопасности: «Accounts: Limit local account use of blank passwords to console logon only». По умолчанию - выключена. Включили.

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

Клиент был неприятно удивлён, что такое вообще возможно. Мы тоже каждый раз удивляемся, хотя видим это регулярно. Система не виновата - она настроена так, как её настроили, а не настроили - значит, по умолчанию. Умолчания безопасными не бывают.