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

Материал из Википедии — свободной энциклопедии
Данная страница не проверялась участниками с соответствующими правами.
Перейти к навигации Перейти к поиску

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

Аспекты

[править | править код]

Типичные компоненты политики паролей:

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

[править | править код]

См. также: Сложность пароля

Для многих политик требуется минимальная длина пароля. Восемь символов является типичным, но не может быть подходящим[2][3][4]. Более длинные пароли обычно более безопасны, но некоторые системы устанавливают максимальную длину для совместимости с устаревшими системами.

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

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

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

Чёрные списки паролей

[править | править код]

Чёрные списки паролей — это списки паролей, которые всегда заблокированы. Чёрные списки содержат пароли, составленные из комбинаций символов, которые в противном случае соответствуют политике компании, но больше не должны использоваться, поскольку они считаются небезопасными по одной или нескольким причинам. Типичными примерами являются Пароль1, Qwerty123, или Qaz123wsx.

Срок действия пароля

[править | править код]

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

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

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

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

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

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

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

Санкции

[править | править код]

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

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

[править | править код]

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

Вопросы удобства использования

[править | править код]

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

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

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

Доступны и другие подходы, которые обычно считаются более безопасными, чем простые пароли. К ним относятся использование токена безопасности или системы одноразовых паролей, например S/Key, или многофакторная аутентификация[11]. Тем не менее, эти системы усиливают компромисс между безопасностью и удобством: по словам Шумана Госемаджумдера, все эти системы улучшают безопасность, но приходят "за счет переноса бремени на конечного пользователя."[12].

Рекомендации NIST и ФСБ

[править | править код]

В июне 2017 года Национальный институт стандартов и технологий США (NIST) выпустил новый пересмотр своих руководящих принципов цифровой аутентификации, NIST SP 800-63B-3[13]. Сравним эти принципы с правилами по обеспечению защиты от НСД Федеральной службы безопасности Российской Федерации (ФСБ)[источник не указан 584 дня].

NIST ФСБ
  • Пароли должны быть длиной не менее 8 символов, если они выбраны подписчиком
  • Системы проверки паролей должны позволять использовать пароли, выбранные подписчиком, длиной не менее 64 символов
  • Верификаторы могут заменить несколько последовательных пробелов одним пробелом до начала верификации, при условии, что результат будет иметь длину не менее 8 символов, но усечение пароля не производится
 Длина пароля должна быть не менее 6 символов
  • Все печатные символы ASCII, а также пробел должны быть допустимы в паролях. Допускается также использование символов Юникода, но тогда ещё до шифровки пароль должен пройти совместимую (де)композицию (NFKD/NFKC)
  • Проверяющие не должны навязывать другие правила составления паролей (например, требовать смешения различных типов символов или запрещать последовательно повторяющиеся символы)
  • Верификаторы должны предлагать подписчику рекомендации, например измеритель надёжности пароля, чтобы помочь пользователю выбрать надёжный пароль. Это особенно важно после отказа от пароля в приведённом выше списке, поскольку это препятствует тривиальной модификации занесённых в чёрный список (и, вероятно, очень слабых) паролей
 В числе символов пароля обязательно должны присутствовать буквы в верхнем и

нижнем регистрах, цифры и специальные символы

(@, #, $, &, *, % и т.п.)

При обработке запросов на установление или изменение паролей проверяющие сравнивают предполагаемые пароли со списком, содержащим значения, известные как часто используемые, ожидаемые или скомпрометированные. Если выбранный пароль найден в списке, верификатор сообщает подписчику, что необходимо выбрать другой пароль, и указывает причину отказа. Список может включать, но не ограничивается:
  • Скомпрометированные пароли — потенциально утёкшие или найденные в базах утечек[14]
  • Словарные слова
  • Пароли, состоящие из повторяющихся или последовательных символов (например, ‘aaaaaa’, ‘1234abcd’).
  • Контекстно-зависимые слова, такие как имя службы, имя пользователя и производные от него
 Пароль не должен включать в себя легко вычисляемые сочетания символов (имена, фамилии и т. д.), а также общепринятые сокращения (USER, ADMIN, ALEX и т. д.)
  • Верификаторы должны реализовать механизм ограничения скорости, который эффективно ограничивает количество неудачных попыток аутентификации, которые могут быть сделаны на счёте абонента
  • Проверяющие должны хранить пароли в форме, устойчивой к атакам в автономном режиме. Пароли должны быть засолены и хешированы с использованием подходящей односторонней функции формирования ключа. Функции формирования ключа принимают пароль, соль и коэффициент затрат в качестве входных данных, а затем генерируют хеш пароля
 При смене пароля новое значение должно отличаться от предыдущего не менее чем в 4-x позициях
Верификаторы не должны позволять абоненту хранить "подсказку“, доступную неаутентифицированному заявителю, и верификаторы не должны побуждать абонентов использовать определённые типы информации (например," как звали вашего первого питомца?”) при выборе паролей Личный пароль пользователь не имеет права сообщать никому
Верификаторы не должны требовать произвольного изменения паролей (например, периодически). Тем не менее, верификаторы должны принудить изменить, если есть доказательства компрометации пароля Периодичность смены пароля определяется принятой политикой безопасности, но не должна превышать 6 месяцев

Применение политики

[править | править код]

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

Большинство компаний требуют от пользователей ознакомиться с политикой паролей, так же компания будет требовать от сотрудников быть в курсе правил безопасности, однако зачастую трудно обеспечить соответствующую политику. Многие системы, например Microsoft Windows, которые требуют пароли, имеют встроенные методы соблюдения установленной политики. Это единственный надёжный способ обеспечить выполнимость этой политики.

См. также

[править | править код]

Примечания

[править | править код]
  1. ↑ Improving Usability of Password Management with Standardized Password Policies Архивная копия от 20 июня 2013 на Wayback Machine. Retrieved on 2012-10-12.
  2. ↑ "Password Complexity Requirements" Архивная копия от 29 октября 2013 на Wayback Machine. The Bug Charmer. September 7, 2012.
  3. ↑ "How long should passwords be?" Архивная копия от 20 сентября 2012 на Wayback Machine. The Bug Charmer. June 20, 2016.
  4. ↑ John D. Sutter (August 20, 2010). "How to create a 'super password'" Архивная копия от 30 ноября 2018 на Wayback Machine. CNN. Retrieved August 31, 2016.
  5. ↑ "The problems with forcing regular password expiry". IA Matters. CESG: the Information Security Arm of GCHQ. 15 April 2016. Archived from the original on 17 August 2016. Retrieved 5 Aug 2016.
  6. ↑ spaf (April 19, 2006). "Security Myths and Passwords" Архивная копия от 30 ноября 2018 на Wayback Machine. CERIAS.
  7. ↑ "Tip: Best Practices for Enforcing Password Policies" Архивная копия от 15 декабря 2018 на Wayback Machine. Microsoft. Retrieved 2018-03-01.
  8. ↑ Yinqian Zhang; Fabian Monrose; Michael K. Reiter (2010). The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis Архивная копия от 11 марта 2014 на Wayback Machine (PDF). Proceedings of the 17th ACM conference on Computer and communications security. New York, NY, US. pp. 176–186. doi:10.1145/1866307.1866328.
  9. ↑ "Choosing Secure Passwords" Архивная копия от 29 ноября 2018 на Wayback Machine. BoingBoing. March 2014 – via Schneier on Security.
  10. ↑ Where do security polices come from? Архивная копия от 20 февраля 2019 на Wayback Machine Proc. Symp. Usable Privacy and Security, 2010
  11. ↑ spaf (May 11, 2006). "Passwords and Myth". CERIAS.
  12. ↑ Rosenbush, Steven; Norton, Steven (May 27, 2015). "For CISOs, IRS Breach Highlights Tension Between Security and User Convenience" Архивная копия от 23 января 2019 на Wayback Machine. The Wall Street Journal.
  13. ↑ Grassi Paul A (June 2017). "SP 800-63B-3 – Digital Identity Guidelines, Authentication and Lifecycle Management" Архивная копия от 1 апреля 2019 на Wayback Machine (PDF). NIST. doi:10.6028/NIST.SP.800-63b Архивная копия от 1 апреля 2019 на Wayback Machine. Retrieved August 6, 2017. This article incorporates text from this source, which is in the public domain.
  14. ↑ Skullsecurity list of breached password collections. Дата обращения: 4 декабря 2018. Архивировано 15 декабря 2019 года.
Источник — https://ru.wikipedia.org/wiki/Политика_паролей