Политика паролей

Политика использования компьютерных паролей

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

Рекомендации NIST

Национальный институт стандартов и технологий (NIST) Министерства торговли США выпустил два стандарта политик в отношении паролей, которые получили широкое распространение.

2004

С 2004 года "Специальная публикация NIST 800-63. Приложение A" [2] рекомендовала людям использовать нерегулярные заглавные буквы, специальные символы и по крайней мере одну цифру. Это был совет, которому следовали большинство систем, и он был "включен" в ряд стандартов, которым должны были следовать предприятия.

2017

Однако в 2017 году крупное обновление изменило этот совет, в частности, теперь принудительное усложнение и регулярные изменения считаются плохой практикой. [3] [4] : 5.1.1.2 

Ключевые моменты из них:

  • Проверяющие не должны навязывать правила композиции (например, не требовать смешивания различных типов символов и не запрещать последовательно повторяющиеся символы) (обратите внимание, что это было изменено в редакции 4 с «не следует » на «не следует» ) [ 5]
  • Проверяющие не должны требовать произвольной или регулярной смены паролей (например, отсутствие правила смены каждые 90 или 365 дней)
  • Пароли должны быть длиной не менее 8 символов.
  • Системы паролей должны позволять абоненту выбирать пароли длиной не менее 64 символов.
  • Все печатные символы ASCII , пробел и символы Unicode должны быть приемлемы в паролях.
  • При установке или смене паролей верификатор должен уведомить абонента о необходимости выбора другого пароля, если он выбрал слабый или скомпрометированный пароль.
  • Проверяющие должны предлагать рекомендации, такие как средство проверки надежности пароля, чтобы помочь пользователю выбрать надежный пароль.
  • Проверяющие должны хранить пароли в форме, устойчивой к офлайн-атакам. Пароли должны быть солеными и хэшированными с использованием подходящей односторонней функции деривации ключа . Функции деривации ключа принимают пароль, соль и фактор стоимости в качестве входных данных, а затем генерируют хэш пароля. Их цель — сделать каждую попытку подбора пароля злоумышленником, получившим файл хеша пароля, дорогостоящей и, следовательно, стоимость атаки подбора высокой или непомерной.

NIST включил обоснование новых рекомендаций в Приложение A.

Аспекты

Типичные компоненты политики паролей включают в себя:

Длина и формирование пароля

Многие политики требуют минимальной длины пароля. Восемь символов — типичное значение, но оно может быть неподходящим. [6] [7] [8] Более длинные пароли почти всегда более безопасны, но некоторые системы устанавливают максимальную длину для совместимости с устаревшими системами .

Некоторые политики предполагают или налагают требования относительно того, какой тип пароля может выбрать пользователь, например:

  • использование как заглавных, так и строчных букв ( чувствительность к регистру )
  • включение одной или нескольких числовых цифр
  • включение специальных символов , таких как @, #, $
  • запрет слов, найденных в списке блокировки паролей
  • запрет слов, содержащихся в личной информации пользователя
  • запрет на использование названия компании или аббревиатуры
  • запрет на использование паролей, соответствующих формату календарных дат, номерных знаков автомобилей , телефонных номеров или других общих чисел

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

Список заблокированных паролей

Списки заблокированных паролей — это списки паролей, которые всегда заблокированы для использования. Списки заблокированных паролей содержат пароли, составленные из комбинаций символов, которые в остальном соответствуют политике компании, но больше не должны использоваться, поскольку они считаются небезопасными по одной или нескольким причинам, например, их легко угадать, они следуют общему шаблону или публично раскрываются из предыдущих утечек данных . Распространенными примерами являются Password1, Qwerty123 или Qaz123wsx.

Длительность пароля

Некоторые политики требуют от пользователей периодически менять пароли, часто каждые 90 или 180 дней. Однако преимущество истечения срока действия пароля является спорным. [9] [10] Системы, реализующие такие политики, иногда не позволяют пользователям выбирать пароль, слишком близкий к предыдущему выбору. [11]

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

Необходимо также учитывать человеческие аспекты паролей. В отличие от компьютеров, пользователи-люди не могут удалить одну память и заменить ее другой. Следовательно, частое изменение запомненного пароля является нагрузкой на человеческую память, и большинство пользователей прибегают к выбору пароля, который относительно легко угадать (см. Усталость от пароля ). Пользователям часто советуют использовать мнемонические приемы для запоминания сложных паролей. Однако, если пароль необходимо неоднократно менять, мнемоника бесполезна, поскольку пользователь не запомнит, какую мнемонику использовать. Кроме того, использование мнемоники (приводящее к таким паролям, как «2BOrNot2B») делает пароль более угадываемым.

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

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

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

Брюс Шнайер утверждает, что «практически все, что можно запомнить, можно взломать», и рекомендует схему, которая использует пароли, которые не встречаются ни в одном словаре. [13]

Санкция

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

Процесс отбора

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

Соображения по удобству использования

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

  • Требование чрезмерно сложных паролей и их частая смена могут привести к тому, что пользователи будут записывать пароли в местах, которые злоумышленник легко сможет найти, например, в картотеке Rolodex или на стикерах рядом с компьютером.
  • Пользователи часто имеют десятки паролей для управления. Возможно, более реалистично рекомендовать использовать один пароль для всех приложений с низким уровнем безопасности, таких как чтение онлайн-газет и доступ к развлекательным веб-сайтам.
  • Аналогично, требование, чтобы пользователи никогда не записывали свои пароли, может быть нереалистичным и привести к тому, что пользователи будут выбирать слабые пароли (или вызывать массу неудобств, когда пользователи забывают свой пароль). Альтернативой является предложение хранить записанные пароли в безопасном месте, например, в сейфе или зашифрованном главном файле. Обоснованность этого подхода зависит от того, какая угроза считается наиболее вероятной. Хотя запись пароля может быть проблематичной, если потенциальные злоумышленники имеют доступ к защищенному хранилищу, если угроза в первую очередь исходит от удаленных злоумышленников, не имеющих доступа к хранилищу, это может быть очень безопасным методом.
  • Включение специальных символов может стать проблемой, если пользователю необходимо войти в систему на компьютере в другой стране. Некоторые специальные символы может быть трудно или невозможно найти на клавиатурах, предназначенных для другого языка.
  • Некоторые системы управления идентификацией позволяют самостоятельно сбрасывать пароль , при этом пользователи могут обойти защиту пароля, указав ответ на один или несколько вопросов безопасности, например «Где вы родились?», «Какой ваш любимый фильм?» и т. д. Часто ответы на эти вопросы можно легко получить с помощью социальной инженерии , фишинга или простого исследования.

Исследование политик паролей 75 различных веб-сайтов, проведенное в 2010 году, пришло к выводу, что безопасность лишь отчасти объясняет более строгие политики: монопольные поставщики услуг, такие как правительственные сайты, имеют более строгие политики, чем сайты, где потребители имеют выбор (например, розничные сайты и банки). Исследование приходит к выводу, что сайты с более строгими политиками «не имеют больших проблем безопасности, они просто лучше защищены от последствий плохого использования». [15]

Существуют и другие подходы, которые обычно считаются более безопасными, чем простые пароли. Они включают использование токена безопасности или системы одноразовых паролей , такой как S/Key , или многофакторной аутентификации . [16] Однако эти системы усиливают компромисс между безопасностью и удобством: по словам Шумана Госемаджумдера , все эти системы повышают безопасность, но «ценой этого является перенос нагрузки на конечного пользователя». [17]

Смотрите также

Ссылки

  1. ^ Улучшение удобства управления паролями с помощью стандартизированных политик паролей. Получено 12 октября 2012 г.
  2. ^ "Electronic Authentication Guideline" (PDF) . nist.gov . USG . Получено 9 апреля 2020 г. .
  3. ^ Статт, Ник (7 августа 2017 г.). «Рекомендации по паролям обновлены после того, как автор оригинала пожалел о своем совете». The Verge . Получено 9 апреля 2020 г.
  4. ^ Грасси Пол А. (июнь 2017 г.). SP 800-63B-3 – Руководство по цифровой идентификации, аутентификации и управлению жизненным циклом . NIST. doi :10.6028/NIST.SP.800-63b. Общественное достояниеВ данной статье использован текст из этого источника, находящегося в общественном достоянии .
  5. ^ "SP 800-63B-4 – Руководство по цифровой идентификации, аутентификации и управлению жизненным циклом". NIST. Декабрь 2023 г.
  6. ^ «Требования к сложности пароля». The Bug Charmer. 7 сентября 2012 г.
  7. ^ «Какой длины должны быть пароли?». The Bug Charmer. 20 июня 2016 г.
  8. Джон Д. Саттер (20 августа 2010 г.). «Как создать „суперпароль“». CNN . Получено 31 августа 2016 г. .
  9. ^ "Проблемы с принудительной истечением срока действия обычного пароля". IA Matters . CESG: подразделение информационной безопасности GCHQ. 15 апреля 2016 г. Архивировано из оригинала 17 августа 2016 г. Получено 5 августа 2016 г.
  10. ^ spaf (19 апреля 2006 г.). «Мифы о безопасности и пароли». CERIAS.
  11. ^ "Совет: Лучшие практики по обеспечению соблюдения политик паролей". Microsoft . Получено 2018-03-01 .
  12. ^ Yinqian Zhang; Fabian Monrose; Michael K. Reiter (2010). Безопасность современного истечения срока действия пароля: алгоритмическая структура и эмпирический анализ (PDF) . Труды 17-й конференции ACM по компьютерной и коммуникационной безопасности. Нью-Йорк, штат Нью-Йорк, США. С. 176–186. doi :10.1145/1866307.1866328.
  13. ^ «Выбор безопасных паролей». BoingBoing. Март 2014 г. – через Schneier on Security.
  14. ^ Уильямс, Джейми (11 июля 2016 г.). «Когда-нибудь использовали чужой пароль? Отправляйтесь в тюрьму, говорит Девятый округ». Electronic Frontier Foundation .
  15. ^ Флоренсио, Динеи; Херли, Кормак (2010-07-14). Откуда берутся политики безопасности?. SOUPS '10: Труды шестого симпозиума по вопросам конфиденциальности и безопасности, пригодных для использования. стр. 1–14. doi :10.1145/1837110.1837124 – через ACM Digital Library .
  16. ^ spaf (11 мая 2006 г.). «Пароли и миф». CERIAS.
  17. ^ Розенбуш, Стивен; Нортон, Стивен (27 мая 2015 г.). «Для руководителей служб информационной безопасности утечка данных IRS подчеркивает напряженность между безопасностью и удобством пользователя». The Wall Street Journal.
Взято с "https://en.wikipedia.org/w/index.php?title=Password_policy&oldid=1252705970"