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