Я обнаружил, что в некоторых случаях принуждение пользователей к смене пароля на регулярной основе становится большей нагрузкой на обслуживание, а не на помощь в обеспечении безопасности. Кроме того, я видел, как пользователи записывают свои новые пароли, поскольку у них либо не хватает времени для запоминания своих паролей, и их не беспокоит повторное изучение другого.
Какая польза от безопасности для принудительного изменения паролей?
Ответы:
Вот другой пример из дневника SANS:
Правила паролей: меняйте их каждые 25 лет
Есть одно практическое преимущество. Если у кого-то есть ваш пароль, и он хочет только прочитать ваше письмо и остаться незамеченным, он может делать это вечно, если вы в конечном итоге не измените свой пароль для входа. Таким образом, регулярная смена пароля не очень помогает против того, чтобы кто-то взломал и сбил его с вашими товарами, но он ДАЕТ вам возможность избавиться от любых преследователей или шпионов, которые могут иметь доступ к вашей учетной записи. Да, это хорошо Но стоит ли одно только это преимущество хлопот и упомянутых недостатков принуждения пользователей менять свой пароль каждые 90 дней, у меня есть сомнения.
Принудительно меняйте пароль, когда вы его угадываете (запуская программу угадывания пароля для всех ваших пользователей все время).
Трудно спорить с «вы должны изменить свой пароль», когда ответ «почему?» это «потому что мы смогли угадать это слепо». Он автоматически вознаграждает тех, кто выбирает трудно угаданные пароли, и учит ваших пользователей, какие пароли являются слабыми. Если они выберут «пароль1», срок его действия истечет, прежде чем они смогут войти в систему один раз. Если пользователь выберет 16-значный случайный буквенно-цифровой пароль со смешанным регистром, вы никогда не догадаетесь, как и никто другой. Позвольте им держать это очень долго, и они даже смогут запомнить это.
Это компромисс. Требование частой смены пароля приводит к снижению качества паролей. Были даже исследования на этот счет.
При этом единственный надежный способ, который я нашел, чтобы запретить пользователям обмениваться паролями, - это требовать периодической смены паролей. Мой опыт показывает, что 90 дней кажутся достойным компромиссом между удобством использования и безопасностью. Если вы пойдете дольше, люди начнут полагаться на общие пароли - раньше, и вы получите «Ноябрь09», «Декабрь09».
Худшее в принудительном изменении паролей не в том, что вы заставляете людей менять свои пароли. Дело в том, что обычно оно приходит с небольшим предупреждением или без него, и они сразу же сталкиваются с проблемой, с которой им нужно немедленно разобраться, поэтому вместо того, чтобы дать кому-то время придумать хороший пароль, скорее всего, он будет менее безопасным. но проще для запоминания или более безопасным, но просто записывается, что сводит на нет преимущество в безопасности.
Если пароли имеют достаточную сложность, что их нелегко угадать, и они не разделяются между системами, и маловероятно, что они были скомпрометированы, то смена пароля, вероятно, не так уж важна.
Однако, если что-то из этого происходит, и первые два, вероятно, встречаются чаще, чем нет, принуждение людей периодически менять пароль означает, что они, по крайней мере, с меньшей вероятностью будут обмениваться паролями.
Тем не менее, я бы хотел рассказать вашим пользователям о том, что означает хороший пароль, и почему им очень плохо делиться. Записывать их часто, независимо от того, что вы делаете.
Я рекомендую людям выбирать пароль из книги, которую они знают, вспоминая какую-то незнакомую цитату из нее или составляя фразу. Используйте первую букву в каждом слове и где-то там добавьте две цифры. Большинство людей могут помнить это после того, как они напечатали это несколько раз.
Я не вижу никакой пользы в этой практике вообще.
Надежный пароль гораздо важнее. Под сильным я подразумеваю либо 9+ буквенно-цифровых + специальных символов, либо 15+ [az] не только словарный пароль / фразу (это основано на недавнем исследовании стоимости взлома паролей с использованием Amazon EC2).
Системы с удаленным доступом должны иметь программное обеспечение для обнаружения и предотвращения брутфорса (например, fail2ban) на всех предоставляемых сервисах. Это намного важнее, IMO, чем обычная политика смены пароля.
Основная проблема заключается в том, что пароли, как механизм безопасности, воняют.
Если вы просите людей часто менять их, они записывают их. Если вы попросите их использовать 30-буквенные пароли, по крайней мере, с 3 цифрами, 4 заглавными буквами и управляющим символом, они забудут их или запишут или сделают другие глупые вещи. Если они просты, пользователи будут использовать глупые пароли, такие как bunny7 или Bunny7. И они будут использовать один и тот же пароль не для всех, в том числе их порно счета и их HOTMAIL счет.
Мне нравятся такие инструменты, как Mobile OTP , которые позволяют пользователям использовать свой мобильный телефон в качестве инструмента двухфакторной аутентификации.
В долгосрочной перспективе вполне вероятно, что мы каким-то образом окажемся в мире с зашифрованными сертификатами в качестве механизма идентификации пользователя. Такие вещи, как OpenID и CAS упрощают аутентификацию пользователей и обеспечивают удобную единую регистрацию.
В долгосрочной перспективе лучше всего сократить количество раз, когда пользователям необходимо выдавать учетные данные, - избавиться от пароля «HR», пароля «табеля рабочего времени» и пароля «CRM». Объедините их в общую инфраструктуру аутентификации, которая требует от пользователей один раз выдавать свои учетные данные. Затем попросите их использовать что-то вроде MobileOTP или RSA SecurID, который использует двухфакторную аутентификацию.
В краткосрочной перспективе политика паролей станет темой религиозных войн. Просто делайте все, что попросит ваш начальник, и если вы начальник, используйте свое суждение, основываясь на вашей пользовательской базе и ожидаемом профиле безопасности.
Удачи!
Эта практика, которая не совсем бесполезна, была намного важнее давно. Обсуждение этой политики на самом деле контрпродуктивно, поскольку отвлекает внимание от нынешних угроз, которые гораздо серьезнее.
Рассмотреть возможность:
Если вы используете Windows / AD, и для учетной записи не установлен флажок «Учетная запись является конфиденциальной и не может быть делегирована», эта учетная запись может использоваться с помощью олицетворения, и пароль не требуется. Код для этого тривиален.
Если рабочая станция Windows человека скомпрометирована из-за уязвимости безопасности, ее маркер безопасности Windows в памяти можно использовать для доступа к другим компьютерам. Опять же, пароль не требуется.
Кстати, именно по этой второй причине доступ к серверам следует осуществлять только с использованием учетной записи, отличной от обычной учетной записи обычного пользователя. Также обратите внимание, что оба сценария полностью разрушают даже самые надежные механизмы двухфакторной аутентификации.
Лучшее, что может произойти в отношении безопасности паролей, - это перестать обсуждать это и сосредоточиться на более современных и серьезных угрозах.
Дополнительная информация:
Ознакомьтесь с презентацией Люка Дженнингса «Один жетон, чтобы управлять ими всеми»:
http://eusecwest.com/esw08/esw08-jennings.pdf
Insomnia Shell - пример кода, необходимого для взлома токенов на сервере ASP.Net:
http://www.insomniasec.com/releases/tools
Как использовать переход по протоколу и ограниченное делегирование в ASP.NET 2.0
http://msdn.microsoft.com/en-us/library/ms998355.aspx
Ищите «без пароля».
Чем дольше пароль остается неизменным, тем больше вероятность того, что он будет взломан, просто потому, что будет больше возможностей для ситуаций, в которых он может быть взломан (учитывая бесконечное количество времени, что возможно). Это также усложняет изменения в будущем, поскольку пользователь привыкнет к старому. Еще один риск заключается в том, что если он скомпрометирован и пользователь не знает о том факте, что существует вероятность серьезного продолжающегося злоупотребления учетной записью пользователя. Периодические изменения, по крайней мере, уменьшат это, поскольку следующее принудительное изменение пароля сделает скомпрометированный пароль бесполезным.
По моему опыту, сценарий, который, скорее всего, приведет к тому, что пользователи будут записывать пароли, - это отсутствие совместного мышления в вашей инфраструктуре безопасности, например наличие нескольких разных систем, каждая из которых требует своего собственного уникального сочетания имени пользователя и пароля. Бросьте 5 из них на пользователя, и вы получите синдром желтой липкой ноты с местью.
Разумная политика паролей, которая позволяет пользователям выбирать пароли, которые легко запомнить, но которые трудно взломать, в сочетании с хорошим обучением пользователей, надежной интегрированной аутентификацией и достойной политикой блокировки и истечения срока действия, все из которых поддерживаются AUP, явно запрещающим совместное использование паролей, лучший способ.
Если вы кэшируете учетные данные (что большинство людей делают для доступности), то это обязательно. Если компьютер похищен физически и включено кэширование учетных данных, то вор может принудительно отключить компьютер от сети, не опасаясь активации политики блокировки учетной записи. Затем они имеют действительные учетные данные для ваших сетевых ресурсов. Смена этих паролей через регулярные промежутки времени может помочь минимизировать этот ущерб.
Это точная причина, по которой вы никогда не входите в систему с привилегированной учетной записью, вы всегда входите в систему как пользователь с ограниченными правами и повышаете количество индивидуальных приглашений, это предотвращает подделку привилегированных учетных данных в случае кражи / взлома.
Я в лагере никогда не требую смены пароля. Или, как говорится в статье - каждые 25 лет - да, я тогда умру. Хорошо. Вот почему ... У меня есть 12 паролей, которые нужно запомнить на моей работе. Большинство из них меняются, а те, которые меняются, находятся в совершенно разных графиках. Все они имеют разные требования к прочности. Как слабый человек может справиться с этим? Я видел несколько способов: напишите их на белой доске. Запишите их на бумаге и храните в открытом ящике. или мой предпочтительный метод: хранить их в довольно небезопасной электронной таблице Google Doc. Вы никоим образом не можете убедить меня, что любой из этих методов (которые ОЧЕНЬ распространены) не полностью компенсирует крошечную выгоду в плане безопасности, полученную путем внесения изменений.
У меня есть время, чтобы написать этот пост, потому что я жду, когда кто-нибудь из ИТ-службы откроет одну из моих учетных записей. Очевидно, я не обновлял свою таблицу должным образом в прошлый раз. Есть ли исследование, которое вычисляет МИЛЛИАРД $$$, потерянный этой ерундой?