Как создать надёжные пароли и защищать систему с их помощью

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

Как используется пароль в ходе идентификации и аутентификации

Для начала определимся с понятиями. 

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

Во время идентификации субъект предъявляет свой идентификатор, а система проверяет, есть ли такой идентификатор в системе. Если идентификатор в системе есть, субъект проходит идентификацию. Далее следует аутентификация — проверка того, принадлежит ли субъекту доступа предъявленный им идентификатор.

Ближайшим аналогом такой процедуры является предъявление пропуска на входе в вуз. В этом случае пропуск (а если точнее, данные, указанные в пропуске) выступает в роли идентификатора. Не предъявишь пропуск — не пройдёшь идентификацию и тебя не пустят на территорию вуза. При этом у устройства (или охранника), которое проверяет пропуск, есть некая условная база идентификаторов. Когда субъект предъявляет свой идентификатор то система проверяет, есть ли такой идентификатор в базе. А иногда и то, для какого субъекта он задан. Если ответ на этот вопрос является положительным (идентификатор есть в базе), то устройство пропускает субъекта, если нет — то не пропускает.

В рамках этой статьи мы не будем подробно разбирать вопросы, связанные с идентификацией, аутентификацией и авторизацией. Скажу лишь что проводимая проверка подлинности может быть односторонней или взаимной – клиент также может проверить сервер как сервер клиента. Кроме того, согласно ГОСТ Р ИСО/МЭК 27000-2012 аутентификация – это в первую очередь обеспечение гарантии того, что заявленные характеристики объекта являются подлинными. А подлинность — свойство, указывающее, что объект представляет собой то, что он заявляет о себе. 

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

Поэтому рассмотрим некоторые требования безопасности, применяемые к паролям и средствам парольной защиты.

Требования к безопасности пароля и энтропия

Даже такой требовательный стандарт безопасности как PCI DSS (стандарт безопасности данных индустрии платёжных карт) предъявляет к пассворду всего два требования:

• Наличие в пароле и цифр, и букв.
• Длина — не менее семи символов.

Зато к системе использования пароля требования значительно больше, например:

• Менять пароли и (или) парольные фразы пользователей, как минимум, один раз в 90 дней.
• Не использовать групповые, общие и стандартные учётные записи и пароли.

В Windows, в групповых политиках паролей можно включить соответствие паролей требованиям сложности:

Если поставить галочку, система будет проверять, что ваши пароли:

• Не содержат имени учётной записи пользователя или частей полного имени пользователя длиной более двух рядом стоящих знаков.
• Имеют длину не менее 6 знаков.
• Содержать знаки трёх из четырёх категорий (т.н. «алфавит» пароля): латинские заглавные буквы (от A до Z), латинские строчные буквы (от a до z), цифры (от 0 до 9) и отличающиеся от букв и цифр знаки (например !, $, #, %)
• Требования сложности применяются при создании или изменении пароля.

Все остальные требования применяются к процедурам, которые будут обрабатывать пароль, например к сроку хранения пароля.

Атаки полного перебора

Почему требования именно такие? Причина в том, что они важны при оценке устойчивости пароля к атакам полного перебора. Допустим, мы используем в качестве пароля слово «admin». Возможный алфавит для такого пароля состоит только из букв нижнего регистра, которых в алфавите 26. Длина самого пароля составляет 5 символов, поэтому число возможных комбинаций пароля составляет 11881376 (26^5).

Кроме того, существует такое понятие, как энтропия пароля. Согласно википедии, информационная энтропия — мера неопределённости некоторой системы в статистической физике или теории информации. В нашем случае — это непредсказуемость появления какого-либо символа первичного алфавита. Для безопасности пароля учитывается т.н. «число бит энтропии» в пароле. Для «случайного пароля» — такого пароля, источником энтропии для которого служит генератор случайных чисел — число бит энтропии рассчитывается по формуле:

Где

• H – получаемая энтропия
• R – длина набора символов, используемая в качестве пароля (т.н. «алфавит» для пароля)
• L – число символов в пароле
• R^L – общее число возможных комбинаций пароля

Соответственно, возможно рассчитать ту длину пароля, которая будет при определённом значении энтропии:

Рассмотрим это на примере. Допустим, мы используем в качестве пароля слово «admin». Возможный алфавит для такого пароля состоит только из букв нижнего регистра, которых в алфавите 26. Длина самого пароля составляет 5 символов, поэтому энтропия для такого пароля будет составлять:

Таким образом, энтропия пароля «admin» составляет примерно 24 бит. А число возможных комбинаций для пароля длиной 5 символов из алфавита длиной 26 символов, как мы уже подсчитали, равно 11881376.

Тут надо понимать, что злоумышленнику не нужно подбирать все 11881376 вариантов. Пароль может подойти уже на второй, третьей попытке или не подойти вовсе (если начать перебор с середины возможных комбинаций). Именно поэтому для оценки сложности паролей оперируют понятием энтропии.

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

Теперь рассмотрим обратный пример. Какая длина пароля обеспечит нам энтропию в 24 бит при использовании символов английского алфавита в нижнем регистре (длина алфавита – 26 символов)?

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

Другие типы атак

Во-первых, пароль можно подобрать по словарю. В этом случае нельзя оперировать понятием энтропии пароля как мерой безопасности — не будет использован брутфорс отдельных символов. К примеру, есть пароль «password@123». Энтропия такого пароля будет довольно-таки большой (72.5 бита). Однако такой пароль довольно часто используется и поэтому периодически попадает в базы слитых паролей — 4263 раза.

Во-вторых, нельзя заранее сказать, какой алфавит использовался для создания пароля, что затрудняет использование энтропии для оценки устойчивости пароля к брутфорсу. Например, в качестве алфавита для пароля «password» вполне можно использовать набор символов ASCII, что существенно поднимает энтропию пароля. Кроме того, при увеличении длины пароля растёт и его энтропия, например, энтропия пароля «-B:Sr%7w» составляет 52.4 бита а пароля «dLgIRSpti» — 51.3 бита. Из этого следует, что хоть первый пароль примерно в два раза сложнее второго, второй проще запомнить, хотя для него использовался более простой алфавит.

В-третьих, в качестве источника для энтропии должен использоваться надежный генератор случайных чисел. Можете почитать довольно полный обзор того, что используется в качестве источника для энтропии. 

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

• Пароль может быть достаточно сложным с точки зрения энтропии, но встречаться в словаре. Таких словарей даже в открытом доступе существует довольно много. Кроме того, можно проверить пароль на сайте Haveibeenpwned.com — встречался ли он в утечках данных.
• Сам механизм идентификации (и аутентификации — если смотреть шире) может быть построен таким образом, что будет иметь слабости в реализации. Типичный пример — отсутствие блокировки субъекта если он более нескольких раз ввел пароль.
• Слабости криптографического алгоритма генерации ключей (или случайных чисел, лежащих в основе ключей). Пример — атаки на протокол WPS, слабость аппаратной реализации алгоритма шифрования, уязвимости понижающие криптостойкость алгоритма шифрования (хэширования) и т. п.
• Отсутствие «соли» (дополнительной случайной строки) при хранении пароля — хэш соответствует паролю. На Internet-technologies.ru есть гайд по этой теме.

По этим причинам большинство технологий идентификации и аутентификации зависят не только от параметров паролей, но и от организации самого процесса. К примеру, вот некоторые требования из стандарта PCI DSS 3.2, которые относятся к безопасности процедур, затрагиваемых паролями:

• Не использовать пароли к системам и другие параметры безопасности по умолчанию, заданные производителем.
• Удалять все учётные записи разработчиков, тестовые учётные записи и/или учётные записи заказного приложения, идентификаторы пользователей и пароли перед передачей ПО заказчикам или переводом его в производственный режим.
• Управлять уязвимостями, в частности убрать уязвимость «Некорректная обработка ошибок».

Кроме того, в этом же стандарте есть такие требования: «Идентифицировать и аутентифицировать доступ к системным компонентам». В них в частности входят:

• Блокировать идентификатор пользователя не более чем после шести неудачных попыток входа подряд.
• Менять пароли и/или парольные фразы пользователей как минимум один раз в 90 дней.
• Запретить пользователю менять пароль и/или парольную фразу на какие-либо из четырёх последних паролей и/или парольных фраз данного пользователя, использованных им ранее.
• Не использовать групповые, общие и стандартные учётные записи и пароли, а также прочие подобные методы аутентификации.

Настройка защиты паролей в ОС

Большинство из приведённых механизмов можно настроить на уровне ОС. Например, в Windows можно воспользоваться настройкой групповых политик (оснастка gpedit.msc для локального ПК или gpmc.msc для настройки групповых политик домена). Нажмите в ОС «Выполнить» и введите «gpedit.msc». Далее можно открыть редактор групповых политик:

В целом для усиления безопасности достаточно соблюдать ряд простых настроек.

Требования сложности пароля. Настройка реализуется по-разному, в ОС Windows всё достаточно понятно.

Обязательная регулярная смена пароля. Тут важно оценить, как часто необходимо менять пароль. Я рекомендую делать это чаще, чем можно подбирать пароль средствами брутфорса. В зависимости от алфавита такой срок может быть разным. В среднем это раз в три месяца для паролей, удовлетворяющих требованиям сложности в ОС Windows.

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

Запрет использования ранее заданных паролей. Эта функция доступна в некоторых ОС, в частности в Windows. Для этого надо активировать соответствующую настройку:

Запрет использования одинаковых паролей для разных сервисов. Типичной является ситуация, при которой один и тот же пароль используется для разных сервисов. Это несёт серьёзную угрозу безопасности данных. Такое требование желательно вводить на уровне политики безопасности предприятия.

Как создать безопасный пароль

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

• Проверяйте пароли на сложность с учётом энтропии. У хорошего пароля энтропия должна быть не меньше 80 бит, а лучше больше. Для оценки эффективности энтропии можно использовать сайт Passwordstrengthcalculator.com или сервис Ae7.s, где пароль можно также сгенерировать. 
• Старайтесь соблюсти баланс между сложностью запоминания пароля, его длиной, алфавитом и энтропией. 
• Можно проверить пароли на утечку — не встречался ли пароль в БД, которые были использованы для взлома. Это можно сделать при помощи сервиса Haveibeenpwned.com
• Если вы планируете разработку веб-сервиса и в этом сервисе предусматривается идентификация по паролю, то можно использовать возможности библиотеки zxcvbn. Эта довольно полезная библиотека позволяет оценить «безопасность» задаваемых паролей. Однако не стоит использовать особенности работы подобных утилит как критерий абсолютной истины. Доступна демоверсия.

Основа безопасности — это всегда хорошая политика. Требования к такой политике бывают разные, но почти всегда они где-нибудь описаны. Типичный пример — стандарт PCI DSS. Такие стандарты можно использовать как критерии для настройки конкретных параметров — например в ОС Windows. Примерный сценарий (с поправкой на возраст статьи :)) рассмотрен на сайте стандарта. 

Хотите узнать больше о безопасности информационных систем? А может даже найти работу в этой сфере? Тогда приглашаем вас на факультет информационной безопасности GeekUniversity!