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

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

Аспекты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Санкции

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

См. также

Примечания
  1. Improving Usability of Password Management with Standardized Password Policies. Retrieved on 2012-10-12.
  2. "Password Complexity Requirements". The Bug Charmer. September 7, 2012.
  3. "How long should passwords be?". The Bug Charmer. June 20, 2016.
  4. John D. Sutter (August 20, 2010). "How to create a 'super password'". 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". CERIAS.
  7. "Tip: Best Practices for Enforcing Password Policies". 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 (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". BoingBoing. March 2014 – via Schneier on Security.
  10. Where do security polices come from? 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". The Wall Street Journal.
  13. Grassi Paul A (June 2017). "SP 800-63B-3 – Digital Identity Guidelines, Authentication and Lifecycle Management" (PDF). NIST. doi:10.6028/NIST.SP.800-63b. Retrieved August 6, 2017. This article incorporates text from this source, which is in the public domain.
  14. КриптоПро | Профиль пользователя. www.cryptopro.ru. Дата обращения: 14 декабря 2018.
  15. Authlogics Cloud Password Breach Database
  16. Skullsecurity list of breached password collections
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.