Comments 24
Мне кажется что это все изврат. Было бы лучше использовать безпарольные методы аутентикации.
Оно того не стоит. Работников в Сбере ну очень много. Одна только выдача всем и замена потерянных/сломанных токенов выльется в немаленькую сумму.
А вот в добавок пытаться поломать все пароли по кругу типовым софтом и не менее типовыми словарями стоит. Прям выделить кластер залить туда хеши паролей и вперед. Кого сломали - немедленное требование смены пароля.
Ну вы же понимаете, что сложные пароли никто не запомнит, в итоге все эти пароли на стикере на мониторе.
Верно лошадь батарея скрепка. Обучаем людей. И конечно делаем нормальное ССО. Чтобы пароль реально один раз надо было вводить. Только для разблокировки компьютера.
Следить за паролями на мониторах и под клавиатурами несложно. Громко и много раз запрещаем. Потом ночью отправляем команду по кабинетам искать пароли. С санкциями против тех у кого нашли. Публичные санкции лучше, но тут есть вопросы этичности.
Ну запрещать, "обучать", вводить санкции и заставлять страдать - никто не запрещает.
Мы ж ведь здесь про "лучшее" (и самое главное - намного безопаснее) решение обсуждаем?
Если остро стоит вопрос о цене - то для Сбера не думаю что будет проблема заказать у китайцев оптом токены. (между прочим, есть куча опенсорсных решений)
Ну запрещать, "обучать", вводить санкции и заставлять страдать - никто не запрещает. Мы ж ведь здесь про "лучшее" решение обсуждаем?
Так это и есть лучшее с учетом местных особенностей.
Токен лучше. Отпечаток на ноуте лучше. Но слишком дорого для многих случаев.
Если остро стоит вопрос о цене - то для Сбера не думаю что будет проблема заказать у китайцев оптом токены. (между прочим, есть куча опенсорсных решений)
Цена токена ерунда по сравнению с ценой инфраструктуры работы с ними. Раздавать, заменять, отзывать по всем отделениям. Даже воон в той деревне.
И делать это быстро. Человек без него работать не может. Это чистые расходы.
хмм, я возможно не в теме, но ведь виндовс из коробки поддерживает u2f токены. Надо только в домене их зарегистрировать и полиси поменять, нет?
Почти. В целом да. Не уверен есть ли XP в дальних отделениях, но наверно их пора обновить уже. И не уверен нет ли планов на переход на тонкие клиенты с линуксом каким. Там все может оказаться сложнее.
Проблему логистики это не снимает. Держать большой запас в каждом дальнем отделении дорого. Проблема потерянных/сломанных будет регулярно везде. Даже с типовой политикой "раз в год/два ломать можно бесплатно, второй раз вычитаем из зарплаты". Почта ходит не так часто и не так быстро чтобы на нее это повесить.
Чтобы быть конкретнее: Вы в отделении в дальней деревне назначили ответственного за одобрение новых токенов. И этот ответственный сломал свой токен. Через день свои токены сломали оба работника этого отделения. Что делать будете? Бабушки уже штурмуют ваше отделение и грозятся писать Путину потому что вы им пенсии не выдаете. На масштабах Сбера это не умозрительный эксперимент, а абсолютно реальный кейс.
Это все решаемо, но за деньги. Видимо сумма оказалась больше потенциальной пользы.
лошадь батарея скрепка.
Ну и получим кучу паролей вроде «мир труд май» и «я помню чудное мгновенье»
Шифрование передаваемого пароля каким-нибудь легким шифром (однако, это может увеличить нагрузку на сам контроллер и БД, так как в БД придется хранить уже шифрованный пароль, а это потребует большего объема оперативной памяти, так как хеш-сумма обычно длиннее, чем сам пароль).
Так всё же шифрование или хеширование? Это разные вещи. У зашифрованного пароля нет хеш-суммы...
Я бы рекомендовал хеширование. Вычисление хеш-суммы быстрая операция, хранить в памяти хеши тоже проще, т.к. они все фиксированной длины. Поиск по ним даже в БД будет быстрее, чем по произвольным текстовым строкам разной длины. Ну и пароль у вас однозначно нигде не идет в открытом виде, более того, даже разработчики не смогут сказать какой именно "плохой" пароль был использован пользователем. Из минусов, вставка в конце "123" полностью меняет хеш, но и в текущей реализации это тоже позволяет обойти базу паролей, если там нет дополнительных регулярок или иных правил.
Кстати хранение "плохих" хешей в БД и их сравнение с хешем пароля (который приходит из DLL), полностью решает проблему утечки БД.
Кстати да. Вариант с хэшами единственный приемлемый с точки зрения безопасности. Правда тогда админы не смогут подсмотреть чей-то пароль, что по видимому было скрытой целью. Ведь имея журнал проверки и доступ к АД хранящей дату/время смены пароля, найти юзернейм довольно несложно.
Насчёт длины хэша - sha96 имеет длину всего 12 байт что короче рекомендованной минимальной длинны паролей (12 unicode chars).
Хотя все равно остаётся слабое место в момент получения хэша, так как при существующей схеме пароль приходит в явном виде.
Да, такое решение создает еще одну потенциальную брешь в безопасности. Я так думаю, что получить сертификацию ФСТЭК и ФСБ будет проблематично, т.к. это решение попадает под требования 152 ФЗ о персональных данных. Поэтому большим и средним компаниям лучше применять готовые решения класса Identity Management, а малым это скорее всего не нужно.
Вот если вы делаете авторизацию пользоватетелей на своем сайте, тогда подобные фильтры имееют смысл, все равно пароли Google будет хранить. :)
Добрый день! Да, вы правы, имелось ввиду все-таки хеширование. Хеширование будет более приемлемым для контроллера и БД чем шифрование, вы все верно написали. Кстати, по поводу вставки «123» - с этим тоже можно бороться путём расширения сервиса и реализации нескольких этапов проверки, где первым этапом будет как раз проверка на известные последовательности. Но это уже может быть сложным для пользователя, нужно балансировать.
Статью скорректировал, спасибо!
Я просто оставлю это тут https://github.com/lithnet/ad-password-protection (проверка по словарям с нормализацией, расширенное управление политиками сложности и т.п). Годное
Ага, хотелось бы услышать что с Lithnet не так и почему пришлось пилить свое?
Добрый день! Сравнение текущего решения и решения Lithnet не производили. Потратил пару минут на чтение их документации и вижу, как минимум, различие в подходе к хранению словаря. В их решении (при любом из 3-х типов хранения) файл с паролями будет считываться для хранения в памяти. А если он считывается, значит это увеличивает размер процесса lssass, что в свою очередь:
Не позволяет хранить большой перечень утекших паролей, так как память на контроллере ограничена. Пусть даже и в бинарном виде.
Затрагивает отказоустойчивость каждого контроллера и обеспечивает высокое влияние на весь ландшафт, так как контроллеров могут быть десятки и даже сотни штук.
Выставляет высокие требования к содержанию словаря (вероятно). Я не знаю, как у них обрабатываются ошибки, но в других схожих решениях я встречал проблему с наличием ошибок или непонятных символов в словаре (например, наличие кириллицы или пробелов в пароле). Данная проблема приводила к ошибке считывания файла словаря и дампу процесса, и как результат, к перезагрузке контроллера.
Подводя короткий итог могу сказать, что наличие отдельной базы данных выглядит более устойчивым и более выгодным для использования в промышленной среде с точки зрения обеспечения бесперебойной работы, обслуживания серверов, разделения доступа и обновления словаря в целом.
Спасибо за развернутый ответ!
Ни в коем случае не утверждаю, что один продукт лучше другого, нужно больше и разных!
Есть развернутое решение от Lithnet + база от haveibeenpwned + ~8000 пользователей. База занимает на диске 11Гб и 65000 файлов, каждый файл весит ~180КБ (подозреваю что при увеличении самой базы - размеры этих мелких файлов увеличатся). Т.е. при поиске нужного пароля не вся база тянется в память, а только нужные, в данном случае, 180Кб. lsass не замечен за увеличенным потреблением памяти.
База хранится на файловом сервере с доступом на чтение только для контроллеров домена. Как показала практика - в моем случае нет нужды ее дублировать на каждый из контроллеров, да и обновлять/дополнять ее сильно проще и один раз.
Также считаю, что сделать отказоустойчивый файловый сервер (а если у вас уже есть несколько контроллеров домена - сильно вероятно, что подобный файловый сервер уже имеется) имхо сильно проще чем правильно настраивать Java, БД, как-то резервировать это, обслуживать и т.д.
На отказоустойчивость самого контроллера домена подобное решение не влияет никак - если он не смог найти пароль в базе (проблемы сети, сервер недоступен или еще что) пароль просто пропускается.
Логирование в eventlog также присутствует.
Ну и вкусное: настраивается это все через GPO достаточно гибко и интересно. Пока правда разом на весь домен (GPO вешается на все контроллеры домена), но разработчики обещают ближайшем будущем от этого уйти. Ну и PowerShell-модуль для управления, настройки и тестирования.
В общем обратите внимание на эту штуку =)
Что-то сделанное своими руками в Windows инфраструктуре - это отличный опыт, который в любом случае будет полезен, как с теоретической, так и практической (понимания угроз и их процессов изнутри) точек зрения. Можете подробнее рассказать об библиотеке OpenPasswordFilter.dll? (на гитхабе я посмотрел на проект, хотелось бы услышать об практике работы с ним)
В данном случае всё же человеческий фактор решает больше. Со временем неиспользованных паролей станет меньше, чем использованных, и можно будет идти от обратного, зная, что внедрена такая система. Так что палка о двух концах
Weak Pass Detector – запрет на использование утекших паролей в контроллере домена