Я должен вынудить своих пользователей изменить пароли каждый n дни/недели/месяц?

Я думаю, что информация пользователям важна. Объясните им, как создать пароль и как важный это не должно использовать тот же пароль дважды. Простой способ создать пароль состоит в том, чтобы взять предложение и взять первую букву в каждом слове и добавить некоторые числа.

Напр. Мне нравится управлять миром = Iltrw99

Не вынуждайте их изменить пароль, он только смутит их.

Если для приложения нужен такой высокий уровень безопасности, Вы рассмотрели использование чего-то как маркеры SecurID? Они означают, что пользователь получает новый пароль каждые 60 секунд; Вы не должны волновать по поводу них использование, записывая пароли. Однако они действительно стоят денег. Насколько безопасный решение должно быть?

Необходимо вынудить пользователей измениться каждый n дни, если политика безопасности требует его. Я работаю на государственное агентство, и это - требование, осуществленное из офиса Аудитора состояния. Я не могу делать с этим вещь, таким образом, я должен вызвать изменения.

Если Вы не обязаны регулированием вызвать изменения пароля, не вынуждайте их. Удостоверьтесь, чтобы пароли, которые действительно становятся установленными, отвечали определенным минимальным требованиям сложности. Длина превосходит сложность для большинства систем пароля, таким образом, переменный стандарт является лучшим случаем, по-моему. Такой как:

• Никакой пароль не должен быть меньше чем 10 символами.
• Пароли между 10-25 символами потребуют по крайней мере 3 наборов символов.
• Пароли между 25-40 символами потребуют по крайней мере 2 наборов символов.
• Пароли дольше, чем 40 символов могут использовать односимвольный набор.

Встроенные схемы сложности вещей как Active Directory не поддерживают этот вид многоуровневой системы. При создании собственной среды изменения пароля, можно сделать материал как это. Поскольку каждое использование клавиши Shift увеличивает вероятность события толстого пальца, длинные пароли с несколькими наборами символов, НАМНОГО более вероятно, подвергнутся событиям неудавшегося входа в систему, особенно во время этапов изучения. При наличии системы локаута учетной записи это может быть большой проблемой. Для человека, который использует 3-ю строку их любимого стихотворения (63 символа!) как их пароль, не имея необходимость на h@x0r это делает запись быстрой и эффективной.

Если технология или изменение среды риска значительно и Ваши пароли теперь не так сложны, как они должны быть, действительно поместите способом для истечения паролей в течение времени. Люди будут ворчать по необходимости, особенно если Вы никогда не вызывали изменение прежде, но она поможет Вам поддержать свое положение безопасности.

Трудно для предположения паролей хорошая вещь. Осуществление уровней сложности, которые приводят к пользователям, забывающим их пароли или имеющим необходимость записать их, является плохой вещью, потому что любая безопасность, полученная сложностью, полностью потеряна в процессе. В идеальном мире (который является, к сожалению, не, где мы живем) должен быть компромисс баланса между сложностью и удобством использования. Конечно, различные люди будут видеть что точка равновесия в различных местах.

Логика позади регулярно изменяющихся паролей за X дней немного потеряна на мне. Причина, которую я обычно слышу для этого, состоит в том, чтобы ограничить полноценность украденного пароля, на который я отвечаю, что любой реальный ущерб будет почти наверняка нанесен в течение первых нескольких часов так или иначе. например, Fred "знакомится с паролем" Mary's. Если этого не происходит в почти то же время, когда Mary изменяет тот пароль, какое значение он имеет, если он изменяется завтра или в следующем месяце? Это, действительно вероятно, что Fred будет ожидать другая неделя или два перед использованием пароля (предполагающий, что это было намерением все время)?

Очевидно, изменение паролей, если существует какая-либо причина или подозрение, что это может быть необходимо, является целым другим вопросом.

С точки зрения администрирования IT Ваш наилучший вариант состоит в том, чтобы исследовать возможность разрешения Вашему использованию приложения поддержка единой точки входа существующей схемы аутентификации, которую используют Ваши клиенты. Очевидно Active Directory является крупным игроком, но если Ваше приложение работает с политикой, которую уже настроил локальный IT, Вы не должны волноваться об изобретении велосипед.

Так как такие дебаты неожиданно возникли о том, являются ли вынужденные изменения пароля хорошей идеей (хотя я думаю, что это было вторично к Вашему основному вопросу), я думал, что Вы могли бы наслаждаться некоторыми идеями и ссылками здесь. Для большинства ситуаций, если Вы не собираетесь осуществлять сложность пароля и расписание изменения, у Вас не может также быть паролей вообще - но способ, которым оно реализовало (обучение, поддержка управления, и т.д.) более важно, чем я могу подчеркнуть.

Как пользователь вполне строгой среды политики паролей ("супер трудно для предположения паролей" и пароля, изменяющегося одинаково), мое мнение - то, что только твердый пароль необходим. Хотя потребуется немного для Ваших пользователей для привыкания к нему (особенно, если они будут 12 345 видами пользователей), они должны смочь вспомнить и ввести его легко в течение недели.

Однако я могу предсказать неудобных конечных пользователей, если у Вас есть такие сильные пароли И принуждение Вашего их для изменения.

С точки зрения пользователя, имея необходимость изменить мой пароль невероятно неудобно. Я абсолютно очень не хочу иметь необходимость сделать так и только неохотно использую сайты, в которых я абсолютно нуждаюсь, если они требуют, чтобы я изменил свой пароль.

Также была некоторая дискуссия о том, является ли это действительно хорошей практикой, так как некоторые люди заканчивают тем, что имели необходимость записать свои пароли для запоминания их.

Вы могли реализовать один из тех виджетов, которые показывают людям, насколько сильный (или слабый) их пароль - то, в то время как они заполняют его - я нахожу, что это (sorta) полезный, хотя я не знаю, приводят ли они на самом деле к более сильным паролям.

Нет. Мое личное мнение - то, что это является ненужным и даже контрпродуктивным. Я разглагольствовал на своем блоге, но можно выследить это, если Вам интересно.

Короче говоря, это сводится к двум причинам:

1. То, чтобы вынуждать пользователя постоянно изменить их пароль приводит к неверным паролям.

Не будет никакой нехватки неподтвержденной информации на этом, но она имеет смысл, что, если я вынужден помнить новую вещь каждый x дни, я сделаю те вещи легкими помнить, и вероятно связанный друг с другом.

Пользователи, намного более вероятно, выберут "отгадываемые" пароли как "Jan2010" или "Password05", если они будут знать, что он должен будет скоро измениться. Осуществление строгой политики в отношении символов, вероятно, просто приведет к добавленному восклицательному знаку или полностью записанному имени, а не сокращению. Существует большая разница между технически сложным паролем и тем, который не будет предполагаться.

2. Принуждение регулярных изменений пароля не предотвращает нападения, оно только снижает риск (и не очень)

Думайте об этом - если бы Ваш пароль предположен или обнаружен так или иначе, сколько времени это взяло бы взломщика для использования той информации? Поместите себя в обувь взломщика. Вы только что обнаружили пароль. Разве Вы не вошли бы в систему и извлекли бы каждый бит информации, которую Вы могли немедленно на всякий случай кто-то узнавать? За 30 дней Вы уже получили все, что Вы хотите.

Моя рекомендация:

• Вызовите чрезвычайно строгую политику паролей (как 15 символов с верхним, ниже, числами и специальными символами, без английских слов> 3 символа)
• Никогда не делайте пользовательское изменение их паролем. Если они должны записать пароль на листке бумаги и сохранить его в их кошельке, это прекрасно на самом деле. Люди способны защищать листки бумаги, но не настолько хорошие в запоминании случайных строк символов.

Моя крупная организация (15000 + пользователи) реализованные "изменения пароля" каждые 120 дней Осенью 2009 года. Это - огромная головная боль IT и трата ресурсов поддержки. Каждый раз, когда 120-дневное окно вращается, нам вынудили тысячи пользователей изменять свой пароль...., который многие из них или делают неправильно и блокируют свою учетную запись.... или забывают на следующий день. Наша справочная служба затопляется вызовами пароля даже при том, что мы пытались сделать так же большую часть ее максимально самообслуживания.

Если Вы хотите, чтобы Ваши пользователи/клиенты очень не хотели, когда Вы.... и Ваша линия фронта штат IT записываете Вас во всех шансах изображения, они получают... изменения пароля реализации.

Политики изменения пароля являются флажком в некоторой книге практического руководства Менеджера по ИТ где-нибудь..., и она была записана 15 лет назад. Никто в канавках, кто на самом деле реализует или поддерживает политику, никогда не будет говорить Вам, что это - хорошая идея.

Я обсудил здесь для "паролей" вместо паролей.... толстую партию пользы, которая сделала..., что свет в конце туннеля БЫЛ прибывающим поездом.:)

Пароль является длинной почти неотгадываемой строкой, которую очень легко помнить как, "MyCatIsFromSpainAndICallHimElGato". Или возможно строка из стихотворения или песни.

Если Вы хотите сделать действительно трудным взломать.... путаницу со случаем, добавьте некоторую пунктуацию, измените некоторые на эли, ohs к нулям, к, и т.д... Но сохраните его, помнят - способный.... это - ключ. Существуют даже способы выбрать их так, они текут легко с Ваших пальцев на клавиатуру...., таким образом, Вы не возвращаетесь на всем протяжении между руками или со СДВИГАМИ и странной пунктуацией.

Так...

• Используйте долгие "пароли".
• Протестируйте их внутренне на силу.
• Реализуйте "единую точку входа" через свою всю инфраструктуру, таким образом, клиенты только должны использовать ее несколько раз день.
• Никогда не вынуждайте их изменить его.
• И обучите, обучите, расскажите об их надлежащем использовании.

Матовый

Править: 24.08.2011 XKCD согласовывает и заявила это лучше, чем я.

Изменение паролей часто может приводить к наличию пользователя, записывающего их. Который не является такой плохой идеей по словам Bruce Schneier (http://www.schneier.com/blog/archives/2005/06/write_down_your.html).

Я даже утверждал бы, что наличие безопасности, мешающей удобству использования, может когда-то быть хорошей вещью, просто потому что это напоминает пользователю действовать надежно. Например, в банке, где я работаю, много мер безопасности на месте является театром безопасности (например, распознавание лиц у двери, но парень безопасности откроет дверь для Вас, если распознавание перестанет работать). В то время как те меры не улучшают безопасность с помощью себя, они должны всегда там напоминать нам, что безопасность является важным concerne на работе, что существует некоторый объем входа и проверки продолжения, и что, если Вы добираетесь, пойманное выполнение чего-то "не защищает" Вас, будет в беде.

Конечно, это относится к безопасности за сотрудников банка, она не могла бы относиться к пользователям Вашего веб-сайта...

Если люди записывают простые пароли, что заставляет Вас думать, что они не запишут огромный пароль или супер сложный пароль. То, что действительно выполняют возрастающие изменения пароля, является чисткой идентификатора пользователя, больше не используемого автоматически, и он позволяет, чтобы отдельный пользователь нес некоторую ответственность во всем этом. Люди собираются быть людьми, ища легкую дорогу для выполнения чего-то; повторные пароли и инкрементно измененные пароли могут быть обнаружены и отклонены. Требования сложности могут быть inforced, вызванные изменения пароля могут также открыть глаза не связанных с IT пользователей к их ответственности во всем этом. Большинство пользователей, кого жалуется на изменение пароля, является ленивым, кто притворяется, что изменение их пароля похоже на операцию на открытом сердце. Остановите скуление, будьте ответственны, и прекратите пытаться найти благоприятные условия или искать новое задание с "мягкими" требованиями...

Что-то, что я не видел упомянутый, является внешним доступом к ресурсам.

Я склонен соглашаться, что, если Вы выбираете разумную политику паролей, если кто-то не пишет это вниз, никто, вероятно, не предположит того пароля.

Однако скажем, у Вас есть веб-почта доступный прилегающий объект, теперь у Вас потенциально есть пользователи, вводящие их учетные данные на "любом старом ПК" и IMO, который увеличивает риск для Ваших бизнес-данных, изложенных шпионским ПО/вредоносным программным обеспечением/троянцами и т.д, которое может осуществить сниффинг/украсть тех паролей.

В то время как я не соглашаюсь с изменяющимися паролями каждые три месяца, это - требование, если Ваша компания публично продана, и это - часть того, чтобы быть совместимым SOX. Примечание стороны: Sarbanes-Oxley сосет.