Получив электронное письмо от поставщика, в котором говорится, что они будут заставлять нас менять наш пароль каждые шесть месяцев, мне любопытно узнать, какие политики истечения срока действия пароля используют люди и почему они их используют.
Ответы:
Здесь есть тонкая грань между тем, чтобы никогда не менять его и менять слишком часто. Наличие одних и тех же паролей в течение многих лет часто не является хорошим решением, особенно если оно общедоступно. Но применение жесткой политики его слишком частого изменения также имеет плохие побочные эффекты. Одно место, где я работал, заставляло всех пользователей внутренней сети менять пароли каждые 6 недель, и пароль не мог быть таким же, как шесть предыдущих паролей. Три неправильных пароля заблокировали рабочую станцию, и ИТ-персоналу пришлось ее разблокировать. Это привело к тому, что каждый написал пароль на заметках Post-It, висящих на экране или помещенных в ящик. Страшный сон.
Я бы сказал, что смена пароля раз в 6 месяцев должна быть достаточной. Это позволит избежать тех страшных заметок Post-It.
Я бы предложил использовать немного математики, которая учитывает вашу минимальную сложность пароля, скорость, с которой злоумышленник может угадать пароли, количество открытых вами учетных записей и некоторую информированную информацию о ваших рисках.
Надеюсь, у вас есть какое-то ограничение скорости для подбора пароля. Обычно это происходит через что-то, что временно блокирует учетные записи после некоторого количества плохих паролей.
И, надеюсь, у вас есть какие-то требования к сложности пароля, чтобы «А» и «пароль» не допускались.
Предположим, что после 30 сбоев пароля за 10 минут вы заблокируете учетную запись на 20 минут. Это эффективно ограничивает скорость угадывания пароля до 174 в час или 4176 в день. Но давайте предположим, что это на пользователя.
Предположим, вам требуются пароли из 8 и более символов, содержащие верхний, нижний и цифры, и что вы делаете некоторые проверки словаря, чтобы убедиться, что эти пароли достаточно случайны. В худшем случае все пользователи ставят один верхний и один номер на одно и то же место, и ваш злоумышленник знает это, поэтому у вас есть 10 * 26 ^ 7 (80G) возможных паролей. Лучший случай - 62 ^ 8 (218T).
Таким образом, злоумышленник, использующий любой возможный пароль, ударит их всех в течение 50 000 лет в худшем случае и почти 600 миллионов тысячелетий в лучшем случае. Или, другими словами, учитывая, что за один год у них будет от 1 на 50 000 до 1 на 52 000 000 000 предположений. Если у вас есть база пользователей в 50 000, почти гарантировано, что в худшем случае они попадут в один аккаунт в год и с вероятностью примерно 50% получат один аккаунт каждые 6 месяцев.
А если бы у вас не было ограничения скорости, а злоумышленник мог угадать миллиард паролей в день? Один из 600 шансов попасть в учетную запись в год или виртуальная гарантия получения примерно 80 из ваших 50 000 пользователей в год.
Работайте над этой математикой и выясните, где находится ваш приемлемый уровень риска. И помните, что чем короче вы его установите, тем сложнее будет запомнить пользователей и тем более вероятно, что они запишут это в удобном для злоумышленника месте.
В качестве дополнительного бонуса: если кто-то пытается использовать тысячи паролей на пользователя в день в отношении ваших систем, я действительно надеюсь, что у вас есть какой-то мониторинг, который бы его использовал.
РЕДАКТИРОВАТЬ: Забыл упомянуть: наша фактическая политика составляет 90 дней, но это имеет отношение к выводам, введенным в заблуждение аудиторов безопасности и не имеет ничего общего с реальностью.
90 дней кажется достаточным для большинства сценариев. Моя самая большая проблема - сложность пароля. Больше, чем временные рамки в создании пост-он заметок, является вынужденная сложность. Одно дело избегать словарных слов, а другое - иметь специальные символы, но когда вы начинаете говорить, что никакие символы не могут повторяться или находиться в порядке возрастания / убывания, вы усложняете жизнь своим пользователям. Добавьте это к короткой жизни пароля, и вы только что приветствовали в других вопросах.
Истечение срока действия пароля раздражает и снижает безопасность.
Истечение срока действия пароля защищает от ситуации, когда злоумышленник уже скомпрометировал пароль пользователя, но не имеет механизма, позволяющего выяснить, что это такое, на постоянной основе (например, кейлоггер)
Тем не менее, это также затрудняет запоминание паролей, что повышает вероятность того, что пользователи их запишут.
Поскольку защита от уже скомпрометированного пароля не является действительно необходимой (вы надеетесь), я считаю, что срок действия пароля бесполезен.
Заставьте пользователей выбрать надежный пароль для начала; поощряйте их помнить это, тогда не требуйте, чтобы они когда-либо это изменили, или они в конечном итоге будут записывать их везде.
Если у вас есть устройство, которому требуются гарантии безопасности «от высокого до сверхвысокого», вам лучше использовать аппаратный токен, который генерирует одноразовые пароли, а не полагаться на истечение срока действия пароля.
Основной «выигрыш» для системы с истечением срока действия пароля заключается в том, что вы, в конечном счете, отключите учетную запись, если владелец учетной записи покинет организацию, в качестве дополнительной «проверки и баланса» для «учетной записи» следует отключить, когда владелец учетной записи уходит".
Принудительное истечение срока действия пароля приводит, в лучшем случае, к высококачественным записанным паролям, а в худшем случае - к неверным паролям (на прежнем рабочем месте, когда мы были вынуждены использовать истечение срока действия пароля, я в конечном итоге использовал (по существу) prefixJan2003, prefixFeb2003 и т. Д. , поскольку мой предпочтительный метод генерации паролей (48 случайных битов, закодированных в Base64) не масштабируется до «новых паролей каждый месяц»).
Я думаю, что если вы спросите 10 разных специалистов по безопасности, вы получите 10 разных ответов.
Это во многом зависит от того, насколько критичным является актив, который защищает пароль.
Если у вас есть высокозащищенный ресурс, вам необходимо установить политику истечения срока действия пароля достаточно короткой, чтобы у любого внешнего злоумышленника не было времени взломать пароль. Другая переменная в этой ситуации - какой уровень сложности требуется для паролей.
Для систем с низким и средним уровнем безопасности, я считаю, что политика истечения срока в 6 месяцев очень справедлива.
Для обеспечения высокого уровня безопасности я думаю, что месяц будет лучше, а для «ультра» безопасных установок ожидаются даже более короткие периоды времени.
Мы применяем 90-дневный срок действия пароля для всех присутствующих здесь (включая нас самих).
В основном потому, что это просто лучшие практики. Вероятность того, что кто-то использует «слабый» пароль по сравнению с более сильным паролем, выше, и чем дольше вы его оставляете, тем больше вероятность долгосрочного, необнаруженного нарушения безопасности.
Мы истекаем пароли ежегодно и требуем надежные (желательно случайные) пароли длиной более 10 символов. Мы проводим атаки по словарю на пароли людей, когда они меняют их. Мы сохраняем прошлые хеши паролей, чтобы пароли не могли быть использованы повторно. Мы также проверяем возможные даты в пароле, как сказал Ватин. ;) Последнее было моим дополнением ...
На прежней работе мы старались истекать чаще по поручению нового администратора сетевой безопасности - каждые два месяца. Через две недели после первой вынужденной перемены я обошел его по нашим административным офисам, и мы заглянули под клавиатуры и коврики для мыши. Более чем у 50% из них был пароль, написанный на посте под ним. Он был рад ослабить политику после того, как мы сели и поговорили с административным персоналом - их мнение было, что у них не было достаточно времени, чтобы запомнить.
Большинство наших вещей в эти дни - единый вход в несколько бункеров. Ресурсы кампуса (редко используемые для большинства людей) находятся в одном хранилище, и этот пароль управляется нашей центральной ИТ-группой. Ресурсы департамента (используются ежедневно - логин, электронная почта, редактирование веб-сайта, ксерокс) - это пароль, управляемый нашей группой, срок годности которого истекает. Если люди недовольны разочарованием, мы отмечаем, что на самом деле им нужно запомнить только один пароль.
В настоящее время я генерирую md5sum для случайного файла в / var / log и использую его часть для своих паролей.
У нас было много дискуссий об этом пару лет назад, когда мы начали политику истечения срока действия пароля. Мы только что закончили лекцию по фреймворку с радужными столами у дерева АД, чтобы увидеть, насколько это плохо, и это было довольно ужасно. Потрясающее количество пользователей все еще использовали свой пароль «helpdesk temp» после вызова / сброса пароля для сброса пароля, что-то ужасное, например, 30% использовали «пароль» или какой-то другой вариант в качестве пароля (p @ $$ w0rd и т. Д.) , Это убедило руководство, что это должно было произойти.
Будучи выше, у нас было лето, с которым пришлось бороться при выборе интервала. Многие наши преподаватели не преподают в течение лета, поэтому нашей службе поддержки пришлось подготовиться к звонкам «Я забыл свой пароль», поскольку все они возвращаются в сентябре. Я думаю, и я могу ошибаться, что наш интервал составляет 6 месяцев с исключением летнего квартала. Таким образом, если срок действия пароля 6 месяцев истекает в середине августа, он будет случайным образом перепрограммирован для сброса в конце сентября - начале октября.
Лучший вопрос заключается в том, как часто ваша служебная учетная запись и пароли администратора меняются. Слишком часто те, кажется, освобождаются от политики смены пароля. Кто хочет пройти через все эти сценарии для смены пароля служебной учетной записи? А некоторые системы резервного копирования затрудняют смену используемых паролей, что препятствует смене паролей администратора.
Одна из основных проблем, связанных с истечением срока действия пароля, состоит в том, что людям будет сложно их запомнить, поэтому у вас либо будут люди, использующие слабые или похожие пароли, либо, если ваша политика не позволяет этого, они начнут записывать пароли, чтобы помочь запомнить их. , У вас также будет больше запросов на изменение пароля, когда люди их забудут.
Лично это зависит от того, для чего используется пароль, но я склонен хранить пароль не более 3 месяцев, если это не полная одноразовая учетная запись. Для вещей с более высоким риском каждый месяц или около того хорошо, и вызывающе измените его, если кто-то, кто знает это, уйдет. Поскольку я работаю в небольшой компании по поддержке компьютеров, у нас есть несколько паролей, которые совместно используются многими людьми, поэтому мы не хотим менять их слишком часто из-за сбоев, которые это может вызвать.
Интересные комментарии пока. Конечно, почему всегда обсуждается, что запоминание паролей - это техническая, а не техническая проблема персонала в компании? Какое отношение чья-либо способность к компьютерному оборудованию / программному обеспечению имеет к способности серьезно относиться к безопасности? Будет ли нетехническое лицо выдавать свою кредитную карту или дебетовые пины #? Кроме того, люди, размещающие пароли на своих заметках на столе, должны быть основанием для увольнения. Удивительно, как улучшится память людей, когда они действительно поймут, что безопасность важна, и к ней нужно относиться серьезно. Я не вижу ничего другого в том, что роль дресс-кодов и политики поведения на работе. Следуй правилам или прощай!
Я думаю, что иметь более безопасный пароль гораздо важнее, чем его частую смену, но оба они обязательно необходимы для безопасной системы.
Утверждается, что сложные пароли трудно запомнить, и это приводит к тому, что сотрудники записывают их. Я убежден в этом, что подавляющее большинство атак происходит извне , и даже записать сложный пароль и прикрепить его к монитору более безопасно, чем запоминание простого пароля.
Я использую однократную аутентификацию с использованием пэдов и токенов, поэтому теоретически каждый раз, когда пользователь входит в систему.
Хотя это, возможно, не по теме, одноразовый блокнот кажется лучшим решением.
Точно так же, и, более того, обеспечение того, что пользователь создает надежный пароль и понимает этику, лежащую в основе вашей политики безопасности (не записывайте ее, не делайте это в свой день рождения, никому не передавайте), будет очень много дальше, чем просто заставлять их менять его каждый n-й интервал времени.