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

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

По той же идее, это действительно хорошо, чтобы заставить пользователей использовать супер трудно угадать пароль. Заставьте их использовать?% &% И строчные буквы в верхнем регистре. Я знаю, что очень сложно придумать такой пароль, а потом запомнить его.

Опять же, мы не хотим, чтобы кто-то использовал 12345.

Так. Есть ли какие-либо технические документы на эту тему? Хорошая практика?

Я говорю о сайте, созданном на PHP. MySQL в среде лампы, если это что-то меняет.

Я думаю, что могу быть в этом меньшинством (основываясь на моем ограниченном опыте работы с ИТ-отделами в школе и на работе), но я считаю, что обязательные, основанные на времени политики смены паролей в лучшем случае бесполезны, а в худшем - вредны. Люди, как правило, очень плохо выбирают хорошие пароли и держат их в секрете. Политики истечения срока действия пароля предназначены для смягчения этого, ограничивая время, в течение которого один пароль может быть взломан / спроектирован социальным способом / украден; однако на практике им этого не удается, в первую очередь потому, что они заставляют пользователей постоянно переучивать свой пароль. Из-за того, что пользователю становится сложнее фиксировать свои пароли в памяти, вы в конечном итоге заставляете многих из них выбирать более слабые пароли и / или записывать свои пароли где-нибудь, где их могут найти любопытные глаза.

Кроме того, когда пользователи вынуждены регулярно менять свой пароль, многие пользователи выбирают пароли, которые следуют очень узнаваемому шаблону, например [base string][digit]. Допустим, пользователь хочет использовать имя своего кота Fluffy в качестве пароля. Они могли бы начать с паролем fluffy, а затем изменить его fluffy1, fluffy2, fluffy3и так далее. В этом случае политика не помогает безопасности; даже если пользователь выбирает более безопасную базовую строку, чем fluffy, и даже если он хранит свой пароль в надежном месте, один суффиксный символ, который меняется каждые несколько месяцев, очень мало помогает для ослабления атак на взлом или социальную инженерию.

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

Осенью 2009 года моя большая организация (более 15 000 пользователей) внедряла «смену паролей» каждые 120 дней. Это огромная головная боль ИТ-специалистов и растрата ресурсов поддержки. Каждый раз, когда проходит 120-дневное окно, у нас тысячи пользователей вынуждены менять свой пароль ... что многие из них либо делают неправильно и блокируют свою учетную запись .... или забывают на следующий день. Наша служба поддержки забита паролями, хотя мы старались сделать как можно больше самообслуживания.

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

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

Я приводил здесь аргументы в пользу «парольных фраз» вместо паролей ... много хорошего, что принесло ... этот свет в конце туннеля БЫЛ приближающимся поездом. :)

Парольная фраза - это длинная почти неузнаваемая строка, которую очень легко запомнить, например, «MyCatIsFromSpainAndICallHimElGato». Или, может быть, строка из стихотворения или песни.

Если вы хотите, чтобы это было действительно трудно взломать .... возиться с регистром, добавить некоторые знаки препинания, заменить некоторые на ells, ohs на нули, a на @ и т. Д. ... Но держите их в состоянии запоминания ... Это ключ. Есть даже способы выбрать их, чтобы они легко перетекли от ваших пальцев к клавиатуре ... чтобы вы не прыгал между руками или с помощью SHIFT и странных знаков препинания.

Так...

• Используйте длинные «пароли».
• Проверьте их внутренне на прочность.
• Внедрите «единую регистрацию» во всей вашей инфраструктуре, чтобы клиенты могли использовать ее только один или два раза в день.
• Никогда не заставляйте их изменить это.
• И воспитывать, воспитывать, воспитывать на правильном их использовании.

Matt

РЕДАКТИРОВАТЬ: 24.08.2011 XKCD соглашается и говорит это лучше, чем я.

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

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

1. Принуждение пользователя постоянно менять свой пароль приводит к неправильным паролям.

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

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

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

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

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

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

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

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

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

Как пользователь достаточно строгой среды политики паролей («очень трудно угадать пароли» и смена пароля), я считаю, что нужен только жесткий пароль. Хотя вашим пользователям потребуется некоторое время, чтобы привыкнуть к нему (особенно если они пользователи типа 12345), они смогут легко вспомнить и напечатать его в течение недели.

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

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

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

Смена паролей часто может привести к тому, что пользователь запишет их. По мнению Брюса Шнайера, это неплохая идея ( http://www.schneier.com/blog/archives/2005/06/write_down_your.html ).

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

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

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

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

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

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

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

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

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

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

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

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

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

Не заставляйте их менять пароль, это только смущает их.

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

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

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

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

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