Проверка паролей пользователей домена Windows на стойкость к атаке по словарю без компрометации пароля

[@magnitudo]

Раскройте секрет — сколько пользователей у вас отличилось словарными паролями?

[@Handy761]

107 учеток из примерно 23000.

[@AVX]

Толку от этого всего мало — у 90% могут быть пароли типа Аа123456. Вроде и не словарное, но весьма слабый пароль.

[@Handy761]

Словарь может быть разным. В моем случае это не просто словарь состоящий из слов, а словарь состоящий в том числе из паролей утекших на разных ресурсах. Типа LinkedIn. И там такие пароли в большинстве своем присутствуют.

[@amarao]

Всё то же самое, но с помощью hashcat'а на GPU, с базами тыренных паролей и базовыми пермутациями. Я уверен, что половина паролей окажется сломанными, не смотря на визуально безопасные вида «dribTuj0O».

[@Handy761]

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

[@amarao]

После того, как пароль пробрутили, конфиденциальность уже не актуальна.

[@Handy761]

В корпоративной сети как раз актуальна. Т.к. если мы знаем пароль, то пользователь может оспорить какие-либо свои действия в будущем, мотивируя тем, что его пароль был известен аудитору. Задача как раз не забрутфорсть пароль, а предупредить простой брутфорс в будущем.

[@Deosis]

В хабе https://habrahabr.ru/hub/infosecurity/ ссылка на внешний ресурс и совет запустить программу с правами администратора.
Вы на самом деле подобрали пароль, и пользователь «может оспорить какие-либо свои действия в будущем, мотивируя тем, что его пароль был известен аудитору», и уже вам придется доказывать, что вам неизвестен пароль. Во время генерации хешей достаточно в конец строки вписать исходное слово.

[@amarao]

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

Не вижу разницы.

[@Kusado]

hashcat может на выходе показывать сломанные хеши без уточнения собственно пароля.
Прогнал hashcat по своим хешам — волосы дыбом. 35% паролей за три часа на старой видеокарточке…

[@RuCosinus]

Я прошу прощения, а куда все ссылки из текста подевались?
Вы их вырезали по каким-либо причинам или забыли вставить?

[@Handy761]

Мой косяк. Спасибо. Исправил.

[@Sleuthhound]

Сколько не пытался заставить юзеров делать сложные пароли, даже с помощью политик с периодической сменой, все равно всегда одна история — «Сложный пароль и он записан на бумажку, а бумажка под клавиатурой или куда хуже на мониторе» и это в 99% случаев, всегда.
Как только разрешаешь пароли попроще и не длиннее 8 символов, и без перегибов типа !J~6%bsH&Ns_ то все встает на свои места, пароли хоть и простые (типа 6TsH7jns), зато они в головах юзеров, а не на бумажке под клавиатурой.

[@Izzet]

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

Для Windows систем, знание самого пароля в большинстве случаев не обязательно. Зная хэш, можно запустить программу из под пользователя, посмотреть почту, подключиться по RDP (в некоторых случаях) и т.д.
Pass-the-hash

[@Handy761]

Согласен. Метод не идеален. Будем дорабатывать. Но в моем случае это лучше, чем ничего.

[@videns]

Имхо, правильнее не брутить пароли, а не давать ставить такие простые пароли. В случае с AD есть не очень дорогой софт, который позволяет задавать расширенные политики проверки пароля. Ставится на контроллер домена и реализует нативную механику AD:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms721882(v=vs.85).aspx
Надеюсь, не сочтут за рекламу:
http://anixis.com/products/ppe/password_policy_rules.htm

[@Handy761]

Интересный продукт. Но покупка ПО у нас не так быстра, как хотелось. Поэтому пока выкручиваемся подручными инструментами.

[@varnav]

Новые рекомендации по парольным политикам от Microsoft:

http://research.microsoft.com/pubs/265143/Microsoft_Password_Guidance.pdf

[@DM-Demius]

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

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

[@Handy761]

Сейчас много контор предлагают OTP на базе смартфонов. Типа Google Authenticator.

[@DM-Demius]

Да но это зависимость от конторы, тем более если например эта контора сделает всё, запустит, но не даст права вносить самому изменения в систему и не расскажет как всё это работает. То тогда будет всё завязано на эту контору, а это уже в таком вопросе как доступ к критическим данным будет однозначно давать сильную проблему безопасности.

[@Handy761]

Вы же можете просто купить ПО и все сделать самостоятельно. Тогда от конторы Вы будете получать только техподдержку (по необходимости). И в принципе пускать какую то контору, которая настраивает что то с доступом/паролями и не дает прав на изменение (т.е. контроль над моей системой/сетью) на мой взгляд странно.

[@ov7a]

Правильно ли я понял, что хэши несоленые? Неужели никак нельзя настроить, чтобы они солились?

[@Handy761]

В Windows насколько я знаю, хеши несоленые. И по моему с этим ничего сделать нельзя. По крайней мере я не знаю.