Следует ли заставлять пользователей регулярно сбрасывать свои пароли?

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

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

Почему совет изменили?

Совет регулярно менять пароли изначально был реализован для повышения безопасности. С чисто логической точки зрения совет регулярно обновлять пароли имеет смысл. Однако реальный опыт немного отличается. Исследования показали, что принуждение пользователей к регулярной смене паролей значительно повышает вероятность того, что они начнут использовать аналогичный пароль, который они могут просто увеличить. Например, вместо того, чтобы выбирать пароли типа «9L = Xk & 2>», пользователи будут использовать пароли типа «Spring2019!».

Оказывается, когда люди вынуждены придумывать и запоминать несколько паролей, а затем регулярно их менять, люди постоянно используют легко запоминающиеся пароли, которые более небезопасны. Проблема с инкрементными паролями, такими как «Spring2019!» в том, что они легко угадываются, а затем позволяют легко предсказать будущие изменения. В совокупности это означает, что принудительный сброс пароля подталкивает пользователей к более легкому запоминанию и выбору. поэтому более слабые пароли, которые обычно активно подрывают предполагаемую выгоду от сокращения будущих риск.

Например, в худшем случае хакер может взломать пароль «Spring2019!» в течение нескольких месяцев с момента его вступления в силу. На этом этапе они могут попробовать варианты с «Осень» вместо «Весна», и они, скорее всего, получат доступ. Если компания обнаружит это нарушение безопасности, а затем заставит пользователей изменить свои пароли, это будет справедливо вероятно, что затронутый пользователь просто изменит свой пароль на «Winter2019!» и думаю, что они безопасный. Хакер, зная шаблон, вполне может попробовать это, если снова получит доступ. В зависимости от того, как долго пользователь придерживается этого шаблона, злоумышленник может использовать его для доступа в течение нескольких лет, при этом пользователь будет чувствовать себя в безопасности, поскольку он регулярно меняет свой пароль.

Какой новый совет?

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

В сочетании с этим предлагается ряд других рекомендаций, направленных на создание более надежных паролей. Сюда входит обеспечение того, чтобы все пароли состояли как минимум из восьми символов в абсолютном минимуме и чтобы максимальное количество символов составляло не менее 64 символов. Также рекомендуется, чтобы компании начали отходить от правил сложности в пользу использования блок-листов. использование словарей ненадежных паролей, таких как «ChangeMe!» и «Пароль1», которые имеют много сложностей требования.

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

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