Comments 20
У нас управление паролями реализовано через web-интерфейс (PHP), LDAP и всякие шелл-скрипты.
Пользователь может сменить свой пароль в любое время, но не реже чем раз в 180 дней + ведётся статистика по его предыдущим паролям, чтобы не повторялись последние столько-то штук + проверяется наличие его логина, транслитерированного ФИО и т.п. в пароле в различных вариациях.
Пользователям за неделю до истечения срока действия пароля начинают приходить письма с требованием смены, а если не меняют — отключается интернет и доступ к файловым ресурсам в сети.
А так как у вас в статье — муторно очень, нужна база актуальных мобильных, да и доверять отправку паролей СМС как-то не айс.
Пользователь может сменить свой пароль в любое время, но не реже чем раз в 180 дней + ведётся статистика по его предыдущим паролям, чтобы не повторялись последние столько-то штук + проверяется наличие его логина, транслитерированного ФИО и т.п. в пароле в различных вариациях.
Пользователям за неделю до истечения срока действия пароля начинают приходить письма с требованием смены, а если не меняют — отключается интернет и доступ к файловым ресурсам в сети.
А так как у вас в статье — муторно очень, нужна база актуальных мобильных, да и доверять отправку паролей СМС как-то не айс.
Ну мобилки можно актуализировать в том же AD(это то же LDAP). При отправке СМС я бы ставил атрибут об обязательной смене пароля при логине.
А так все эти поделки от лукавого — полно нормальных IDM с SelfService пользователей.
А так все эти поделки от лукавого — полно нормальных IDM с SelfService пользователей.
У пользователей конечно же есть возможность работать с паролями через web. Это решение — лишь дополнение к другим инструментам.
Интересно было решить данную задачу именно встроенными инструментами: AD + powershell, без использования сторонних программ и сервисов.
Интересно было решить данную задачу именно встроенными инструментами: AD + powershell, без использования сторонних программ и сервисов.
Скажите, а может проще убрать требование к периодической смене пароля, раз уж Вы так легкомысленно относитесь к безопасности?
Отсылать новый пароль в открытом виде по электронной почте (надеюсь, что у вас хотя бы свой почтовый сервер) или в открытом виде в смс, через стороннюю организацию это очень легкомысленно.
А пароль от электронной почты пользователь меняет как часто или Вы это вообще не регламентируете? Тогда это вообще «отлично».
Отсылать новый пароль в открытом виде по электронной почте (надеюсь, что у вас хотя бы свой почтовый сервер) или в открытом виде в смс, через стороннюю организацию это очень легкомысленно.
А пароль от электронной почты пользователь меняет как часто или Вы это вообще не регламентируете? Тогда это вообще «отлично».
Подскажите, как я могу отсылать пароль пользователям не в открытом виде, и я обязательно попробую это реализовать.
Почтовый сервер у нас свой и пароли к почтовым аккаунтам меняются каждый месяц.
Почтовый сервер у нас свой и пароли к почтовым аккаунтам меняются каждый месяц.
Рискую нарваться на критику, но все-же скажу. Периодическая принудительная смена паролей простым пользователям в большинстве случав зло!
Вот человек-пользователь. Он далек в своих помыслах от каких-то там требований к безопасности информационных ресурсов и прочим абстрактным для него вещам. Его основной мотив — простота и путь наименьшего сопротивления. Если ему приходится придумывать пароль самому, он придумает его таким образом, что-бы его легко запомнить. Пароли 123, 111 или просто 1 — наиболее логичный выбор для них. Такой пароль легко запомнить.
Хорошо, говорит админ схватившись за голову. Вот вам ограничение на длинну — не меньше n символов. Ок отвечает пользователь и задает цифрами дату своего рождения или рождения ребёнка. Он инстинктивно стремиться поставить пароль, который он запомнит.
Ладно говорит админ и задаёт критерий сложности к паролю и тут происходит перелом в безопасности. Суть его в том, что человек уже не может запомнить пароль который и вбил то с трудом. И что он делает? Правильно он его записывает на бумажке. Кладет он её в лучшем случае под клавиатуру. В худшем на липкий листок наклеивает прямо на монитор или клавиатуру.
Тут добавляем требование — менять пароли периодически и получаем гарантированный результат. Никто больше не пытается запомнить пароль, а те кто честно пытаются это сделать и не записывать, начинают вам названивать и просить сменить. Отлично, приехали. начинаем административную борьбу!
Начинаем, жаловаться руководству, оно делает вид что согласно и ай-ай и надо бы всех наказать, а сами краем глаза такой-же листочек замечаете у директора под клавиатурой.
Всё-таки, что-то не так написано в учебниках по безопасности. Правила не работают. Слепое следование казалось бы очевидным любому админу правилам безопасности приводит в большинстве случаев к резкому падению той самой безопасности.
В итоге моё личное мнение:
1. Пароль должен быть такой, который пользователь легко и с радостью запомнит (делаем цифры).
2. Пароль должен быть таким, чтобы по словарю его было не подобрать ну и брутфорс небыл слишком быстрым, не быстрее и дешевле чем выпытать из данного юзера свой пароль методами социальной инженерии (проверяем пароль по словарю самых частых паролей).
3. Раздельная политика для системных паролей и пользовательских. Часто получается так, что как раз админы ставят пароли себе попроще и не вводят политику смены паролей для серверных задач (чтоб все не слетело и не забыть если что).
Вот человек-пользователь. Он далек в своих помыслах от каких-то там требований к безопасности информационных ресурсов и прочим абстрактным для него вещам. Его основной мотив — простота и путь наименьшего сопротивления. Если ему приходится придумывать пароль самому, он придумает его таким образом, что-бы его легко запомнить. Пароли 123, 111 или просто 1 — наиболее логичный выбор для них. Такой пароль легко запомнить.
Хорошо, говорит админ схватившись за голову. Вот вам ограничение на длинну — не меньше n символов. Ок отвечает пользователь и задает цифрами дату своего рождения или рождения ребёнка. Он инстинктивно стремиться поставить пароль, который он запомнит.
Ладно говорит админ и задаёт критерий сложности к паролю и тут происходит перелом в безопасности. Суть его в том, что человек уже не может запомнить пароль который и вбил то с трудом. И что он делает? Правильно он его записывает на бумажке. Кладет он её в лучшем случае под клавиатуру. В худшем на липкий листок наклеивает прямо на монитор или клавиатуру.
Тут добавляем требование — менять пароли периодически и получаем гарантированный результат. Никто больше не пытается запомнить пароль, а те кто честно пытаются это сделать и не записывать, начинают вам названивать и просить сменить. Отлично, приехали. начинаем административную борьбу!
Начинаем, жаловаться руководству, оно делает вид что согласно и ай-ай и надо бы всех наказать, а сами краем глаза такой-же листочек замечаете у директора под клавиатурой.
Всё-таки, что-то не так написано в учебниках по безопасности. Правила не работают. Слепое следование казалось бы очевидным любому админу правилам безопасности приводит в большинстве случаев к резкому падению той самой безопасности.
В итоге моё личное мнение:
1. Пароль должен быть такой, который пользователь легко и с радостью запомнит (делаем цифры).
2. Пароль должен быть таким, чтобы по словарю его было не подобрать ну и брутфорс небыл слишком быстрым, не быстрее и дешевле чем выпытать из данного юзера свой пароль методами социальной инженерии (проверяем пароль по словарю самых частых паролей).
3. Раздельная политика для системных паролей и пользовательских. Часто получается так, что как раз админы ставят пароли себе попроще и не вводят политику смены паролей для серверных задач (чтоб все не слетело и не забыть если что).
Ну не обязательно цифры, можно и с буквами сделать запоминаемый пароль, была раньше даже программа такая, ADvanced Password Generator, у которого была функция генерации запоминаемых паролей. Правда, только из букв, цифры приходится самому вручную вставлять.
Конечно же вы нарветесь на критику.
Для начала вы исходите из того, что пользователи неадекватные, низкоквалифицированные люди. Это далеко не всегда так. Большинству вполне реально объяснить зачем нужны сложные пароли и почему их нужно менять. В финансовой и ит сфере с этим как правило нет проблем. Но это больше к социальной инженерии относится. А теперь техническая критика.
1. Сложный пароль на бумажке это гораздо безопаснее простого в памяти. Достаточно обеспечить физическую безопасность бумажки.
2.Ваше личное мнение. П1 и п2 несовместимы. Никак, вообще совсем никогда.
В плане безопасности пароля уже придумано целых 2 решения которые решают большинство проблем.
1. Двухфакторная авторизация. Раздайте всем по токену с простым пинкодом. Хотя это и близкий эквивалент пароля на бумажке в смысле необходимости обеспечения физической безопасности материального объекта.
2. Были проведены исследования длины пароля. 20 символов даже при использовании словарных слов обеспечивают достаточную безопасность. Запомнить фразу из 3-4 слов способен любой.
Для начала вы исходите из того, что пользователи неадекватные, низкоквалифицированные люди. Это далеко не всегда так. Большинству вполне реально объяснить зачем нужны сложные пароли и почему их нужно менять. В финансовой и ит сфере с этим как правило нет проблем. Но это больше к социальной инженерии относится. А теперь техническая критика.
1. Сложный пароль на бумажке это гораздо безопаснее простого в памяти. Достаточно обеспечить физическую безопасность бумажки.
2.Ваше личное мнение. П1 и п2 несовместимы. Никак, вообще совсем никогда.
В плане безопасности пароля уже придумано целых 2 решения которые решают большинство проблем.
1. Двухфакторная авторизация. Раздайте всем по токену с простым пинкодом. Хотя это и близкий эквивалент пароля на бумажке в смысле необходимости обеспечения физической безопасности материального объекта.
2. Были проведены исследования длины пароля. 20 символов даже при использовании словарных слов обеспечивают достаточную безопасность. Запомнить фразу из 3-4 слов способен любой.
Немного поздновато, но всё же. Я думаю тут самое место для этой истории.
1.1
Однажды Сисадмин пожаловался Учителю:
– Мы выдали всем нашим пользователям индивидуальные пароли, а они не желают хранить их в тайне. Записывают на листочках и приклеивают к мониторам. Что нам делать? Как заставить их?
Инь Фу Во спросил:
– Сначала скажи, почему они это делают.
Сисадмин подумал и ответил:
– Может быть, они не считают пароль ценным?
– А разве пароль сам по себе ценный?
– Не сам по себе. Ценна информация, которая под паролем.
– Для кого она ценна?
– Для нашего предприятия.
— А для пользователей?
– Для пользователей, видимо, нет.
– Так и есть, – сказал Учитель. – Под паролем нет ничего ценного для наших работников. Надо, чтоб было.
– Что для них ценно? – спросил Сисадмин.
– Догадайся с трёх раз, – рассмеялся Учитель.
Сисадмин ушёл просветлённый и сделал на корпоративном портале персональные странички для всех работников. И на тех страничках был указан размер зарплаты. Узнав об этом, все пользователи забеспокоились о своих паролях. На другой день в курилке обсуждали размер зарплаты Главбуха. На третий день ни у кого не было видно листочков с паролями.
Например, вы можете в информационном письме указывать ссылку на генератор паролей. Пользователь переходит по этой ссылки и ему отображаются пароли на выбор. Эти пароли нигде не хранятся.
>> Почтовый сервер у нас свой и пароли к почтовым аккаунтам меняются каждый месяц.
В таком случае, я не рекомендую вам и вашим коллегам ссорится с администратором почтового сервера, потому что благодаря вам он со временем получит доступ к паролям всех ваших пользователей.
Расскажите о ежемесячной процедуре смены пароля для почтового ящика?
>> Почтовый сервер у нас свой и пароли к почтовым аккаунтам меняются каждый месяц.
В таком случае, я не рекомендую вам и вашим коллегам ссорится с администратором почтового сервера, потому что благодаря вам он со временем получит доступ к паролям всех ваших пользователей.
Расскажите о ежемесячной процедуре смены пароля для почтового ящика?
Никак. Весь смысл парольной защиты базируется на том, что пароль должен быть известен только пользователю, и он не должен нигде храниться в открытом виде. А делать обязательную смену паролей и при этом генерить их самому и рассылать — это просто профанация. Зачем вы вообще пароли меняете? Формальное требование? Если да, то формально вы его реализовали, но реально безопасность никак не повысили, скорее понизили. :)
Все просто есть сервисы одноразовых ссылок. Или можно самому такой сервис развернуть, если не доверяете внешним серверам. По ссылке лежит зашифрованный пароль.
Ну и еще лучше — если у сотрудника есть смартфон, то сделайте двухфакторную аутентификацию. Даже если пароль кто-то перехватит — без устройства пин-код не получить.
Ну и еще лучше — если у сотрудника есть смартфон, то сделайте двухфакторную аутентификацию. Даже если пароль кто-то перехватит — без устройства пин-код не получить.
Есть давно придуманный пароль «Pa$$word» который упоминается на всех курсах M$, скрипт выполняет сброс на этот пароль или какой-либо другой стандартизированный для вашей организации, и устанавливает признак на смену пароля при первом входе. Высылаете SMS о необходимости сменить пароль (на тот, который придумает он сам).
Мы например в инструкции сразу писали базовый пароль и все пользователи его знали.
Это я к тому, что есть варианты обойти политики.
Мы например в инструкции сразу писали базовый пароль и все пользователи его знали.
Список простых паролей соответствующих стандартной политике, 8 символов.
Многие возможно слышали о таких вещах на курсах.
Помойка1
Помойка2
Помойка3
…
…
Помойка24
«Мой предыдущий пароль»
Помойка1
Помойка2
Помойка3
…
…
Помойка24
«Мой предыдущий пароль»
Это я к тому, что есть варианты обойти политики.
Если будет сброс на стандартный пароль, то это дыра в безопасности. Сотрудник в отпуске, ему сбросили пароль на стандартный, теперь можно пройтись по всем логинам AD и среди них точно найдется несколько тех, кто еще не сменил со стандартного.
Вобщем пароль свой должен знать только сотрудник, даже helpdesk ни в коем случае его знать не должен.
Для привелегированных пользователей (т.е. у тех у кого есть хотя бы чуть более высокие права чем у рядового пользователя) — обязательно необходимо внедрять токены или другой способ двухфакторной аутентификации.
Пароли надо передавать тоже не в чистом виде а одноразовыми ссылками. Сервис одноразовых ссылок использовать свой. Пример onetimesecret.com/ — у него есть исходники. Берете и разворачиваете у себя на серверах.
Вобщем пароль свой должен знать только сотрудник, даже helpdesk ни в коем случае его знать не должен.
Для привелегированных пользователей (т.е. у тех у кого есть хотя бы чуть более высокие права чем у рядового пользователя) — обязательно необходимо внедрять токены или другой способ двухфакторной аутентификации.
Пароли надо передавать тоже не в чистом виде а одноразовыми ссылками. Сервис одноразовых ссылок использовать свой. Пример onetimesecret.com/ — у него есть исходники. Берете и разворачиваете у себя на серверах.
Sign up to leave a comment.
Автоматическое управление паролями в Active Directory