Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так...

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

Мэтт

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

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

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

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

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

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

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, что увеличивает риск для ваших бизнес-данных, создаваемый шпионскими / вредоносными программами / троянами и т. Д., Которые могут прослушивать / красть эти пароли. .

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