Аудит паролей -- старая и избитая тема. Однако, как выяснилось сегодня в общении с приятелем-безопасником, не все до конца понимают, зачем в крупных компаниях нужен аудит паролей.
Сам процесс все представляют себе примерно одинаково -- и хакеры, и пентестеры, и офицеры безопасности. Это перебор NTLM-хэшей из AD[*] с помощью радужных таблиц, причем обязательно на GPU. Модно, современно, быстро... но -- зачем?
Считается, что этот процесс поможет выявить откровенно нестойкие пароли, а также пароли, кажущиеся стойкими, типа p@ssw0rd или 123qweASD, которые присутствуют в популярных словарях для брутфорса. А как только мы такие пароли выявим, мы затем возьмем и... Здесь следует остановиться, отвлечься от утилит для взлома паролей (они прикольные, знаю), включить голову и ответить на вопрос: а какие риски мы тем самым снижаем? Вот мы взяли 80 Гб alphanumeric-таблиц и сломали все пароли за час. Добавим в парольную политику спецсимволы, заставим всех сменить пароли? А затем возьмем еще 400 Гб таблиц, со спецсимволами, и снова все сломаем еще за четыре часа. И пошло-поехало. Пользователи плачут, жалуются на безопасников и невозможность поставить сколь-нибудь удобный пароль, начальство ругается и обвиняет службу ИБ в фашизме. Совершенно справедливо, надо заметить.
Между тем, если в домене включена блокировка учетной записи хотя бы с двадцатой попытки, то для потенциального злоумышленника даже пароль passw0rd2012 -- уже предположительно стойкий. То есть, безопасник своими действиями не выиграл вообще ничего. Ах, у вас блокировка отключена, потому что доменные аккаунты можно снаружи заблокировать брутфорсом через IMAP? Что ж, если вы включаете внутреннюю аутентификацию на внешнем периметре -- поздравляю, тогда аудит паролей далеко не самая важная вещь, которой вам сейчас стоит заняться.
Грамотный безопасник понимает, что аудит паролей призван закрыть совсем другие риски. А именно -- контролировать неконсистентность между разными группами учетных записей. В любой крупной компании есть так называемые "роботные" учетные записи для автоматизированных скриптов и прочих нечеловеков. Их пароли, в отличе от пользовательских, не меняются раз в два или три месяца и процесс смены таких паролей производится вручную. Ну, не хотят админы, чтобы у них вдруг в субботу все процессы сломались, потому что пароли их роботов истекли. Это можно понять. Или вот еще: сервисные учетные записи. Вспомните, вы же сами были обеими руками за перевод всех систем на единую точку аутентификации. Помните, да? А помните ли вы, что после этой инициативы админы еще полгода разбирались с проблемами, что вот в этой системе пароль, оказывается, не может быть больше десяти символов. А вон в той -- не принимает спецсимволы, к тому же после смены пароля все еще и перезагружать надо. Легаси, мать ее. Вот и появляются исключения.
Итак, возвращаясь к теме, где парольные риски? Что плохо? Плохо, когда все роботы ходят в СУБД процессинга под одним и тем же паролем. Плохо, когда пароль системного юзера в какой-нибудь финансовой системе не менялся уже полтора года. А то, что у клерка DOMAIN/vasya пароль оказался vasya_pass2012 -- да и хрен бы с ним.
---
[*] Давайте считать, что 99% т.н. "энтерпрайза" используют AD в качестве централизованного места аутентификации. Давайте также считать, что LM-хэши вы у себя давно уже отключили, все-таки 2012 год на дворе.
Про аудит паролей
