В нескольких случаях я обнаружил, что принуждение пользователей к регулярной смене пароля становится большим бременем для обслуживания, чем помогает в обеспечении безопасности. Кроме того, я видел, как пользователи записывают свои новые пароли, так как у них либо не хватает времени, чтобы запомнить свои пароли, либо им не нужно переучивать другой.
Какое преимущество безопасности дает принудительное изменение паролей?
Принудительно сменить пароль, когда вы его угадываете (постоянно запуская программу подбора пароля для всех ваших пользователей).
Трудно спорить с «вам нужно сменить пароль», когда ответ на «почему?» "потому что мы смогли угадать это вслепую". Он автоматически награждает тех, кто выбирает трудные для угадывания пароли, и учит ваших пользователей, какие пароли слабые. Если они выберут «пароль1», срок его действия истечет до того, как они смогут войти в систему один раз. Если пользователь выберет случайный буквенно-цифровой пароль из 16 символов в смешанном регистре, вы его никогда не угадаете, как и никто другой. Пусть хранят очень долго, и они даже запомнят.
Вот другой вариант из дневника SANS:
Правила паролей: меняйте их каждые 25 лет.
Есть одно практическое преимущество. Если у кого-то есть ваш пароль, и все, что они хотят, - это прочитать вашу электронную почту и остаться незамеченными, они могут делать это навсегда, если вы в конечном итоге не измените свой секрет для входа. Таким образом, регулярная смена пароля не очень помогает против того, чтобы кто-то взломал и ускользнул с вашими товарами, но ДЕЙСТВИТЕЛЬНО дает вам шанс избавиться от сталкеров или шпионов, которые могут получить доступ к вашей учетной записи. Да, это хорошо. Но я сомневаюсь, что само по себе это преимущество стоит хлопот и упомянутых недостатков, связанных с принуждением пользователей менять свой пароль каждые 90 дней.
Это компромисс. Требование частой смены пароля действительно приводит к снижению качества паролей. На этот счет даже проводились исследования.
При этом единственный надежный способ, который я нашел, чтобы запретить пользователям делиться паролями, - это требовать периодической смены паролей. Мой опыт показывает, что 90 дней кажутся достойным компромиссом между удобством использования и безопасностью. Если вы проделаете больше времени, люди начнут полагаться на общие пароли - раньше, и вы получите «November09», «December09».
Худшее в принудительной смене паролей не в том, что вы фактически заставляете людей менять их пароли. Дело в том, что обычно это происходит с небольшим предупреждением или без него, и они сразу же сталкиваются с проблемой, с которой им нужно сразу же справиться, поэтому вместо того, чтобы дать кому-то время придумать хороший пароль, более вероятно, что это будет либо менее безопасный но его легче запомнить или безопаснее, но он просто записывается, что сводит на нет преимущество безопасности.
Если пароли достаточно сложны, их сложно угадать, и они не используются в разных системах, и маловероятно, что он был взломан, то изменение пароля, вероятно, не так уж и важно.
Однако, если что-либо из этого произойдет, а первые два, вероятно, более распространены, чем нет, принуждение людей к периодической смене пароля означает, что они, по крайней мере, с меньшей вероятностью будут делиться паролями.
Тем не менее, я бы предпочел рассказать вашим пользователям о том, что означает хороший пароль и почему очень плохо им делиться. Записывать их - обычное дело, чем бы вы ни занимались.
Я рекомендую людям выбирать пароль из книги, которую они знают, запомнив какую-нибудь не очень знакомую цитату из нее или составив фразу. Используйте первую букву каждого слова и добавьте туда два числа. Большинство людей могут вспомнить это после того, как напечатали его несколько раз.
Я не вижу в этой практике никакой пользы.
Надежный пароль гораздо важнее. Под сильным я подразумеваю либо 9+ буквенно-цифровых + специальных символов, либо 15+ не словарных паролей / фраз (это основано на недавнем исследовании стоимости перебора паролей с использованием Amazon EC2).
Системы с удаленным доступом должны иметь программное обеспечение для обнаружения и предотвращения перебора (например, fail2ban) на всех открытых сервисах. ИМО, это гораздо важнее, чем обычная политика смены пароля.
Основная проблема заключается в том, что пароли как механизм безопасности имеют неприятный запах.
Если вы просите людей часто менять их, они их записывают. Если вы попросите их использовать пароли из 30 букв, по крайней мере, с 3 цифрами, 4 буквами верхнего регистра и управляющим символом, они их забудут или запишут, или сделают другие глупости. Если они простые, пользователи будут использовать глупые пароли, такие как bunny7 или Bunny7. И они будут использовать один и тот же пароль не для всех, в том числе их порно счета и их HOTMAIL счет.
Мне нравятся такие инструменты, как Мобильный 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. Невозможно убедить меня, что какой-либо из этих методов (которые ОЧЕНЬ распространены) полностью не компенсирует крошечное преимущество безопасности, получаемое при необходимости внесения изменений.
У меня есть время написать этот пост, потому что я жду, когда кто-нибудь из ИТ-поддержки разблокирует одну из моих учетных записей. Очевидно, в прошлый раз я неправильно обновил свою электронную таблицу. Есть ли исследование, которое подсчитывает, что из-за этой ерунды потеряли МИЛЛИАРД долларов?