Политики паролей: как не надо делать

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

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

Что такое парольная политика

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

Правила, входящие в парольную политику, могут быть самыми разнообразными:

• Длина пароля — то есть минимальное и максимальное количество символов, из которых должен состоять пароль.
• Набор допустимых символов — должен ли пароль включать заглавные и строчные буквы, цифры, спецсимволы, эмодзи и так далее; или наоборот, не включать что-то из перечисленного.
• Запрет на те или иные комбинации символов — скажем, на то, чтобы пароль содержал последовательность знаков, совпадающую с названием компании или логином пользователя.
• Специфические запреты — например, пароль не может начинаться с единицы, содержать прямую последовательность цифр (борьба с 12345678), не должен совпадать по формату с какими-то легко угадываемыми вещами (дата, телефонный номер, номер автомобиля) и так далее.
• Списки запрещенных паролей — таблицы исключений, которые в целом удовлетворяют всем прочим требованиям, но признаны небезопасными по тем или иным причинам: к примеру, запрет на использование паролей, уже фигурировавших в известных утечках.
• Срок действия пароля — временной интервал, по истечении которого пользователь должен задать новый пароль.
• Запрет на переиспользование паролей — то есть запрет менять пароль на один из уже использованных для данной учетной записи ранее.
• Запрет на смену пароля по инициативе пользователя — такая опция может быть использована для борьбы с угонами учетных записей. То есть это защита от смены пароля злоумышленником.
• Способ хранения пароля — в частности, явный запрет в организации на всеми любимые стикеры с паролями. Или рекомендация пользоваться менеджером паролей.
• Санкции — если какие-то правила парольной политики не получается жестко задать в настройках программного обеспечения, можно принуждать пользователей следовать им с помощью тех или иных административных санкций.

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

Далее в этом посте мы сфокусируемся на том, какие требования стоит и не стоит предъявлять к паролям в рамках парольной политики. И для этого рассмотрим несколько примеров неудачных политик с не самыми осмысленными, а местами так и вовсе смешными правилами.

Примеры неудачных парольных политик

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

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

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

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

Чтобы пользователю не было слишком уж просто, можно попытаться его запутать, приведя не четкий список правил, которым должен удовлетворять пароль, а смутное описание на целый абзац мелким шрифтом. И, конечно же, в нем должно быть ограничение длины пароля смехотворными 6 символами — взломщики будут невероятно благодарны создателю этой парольной политики.

Так заботится о безопасности своих пользователей один из самых больших североамериканских банков:

В некоторых случаях, если придуманный пользователем пароль не удовлетворяет какому-либо из правил парольной политики, ему не рассказывают, какое же именно правило он нарушил. Пусть пользователь угадает сам! Лучшие практики от одной крупной международной сети продуктовых магазинов:

Правильное отношение к пользовательским паролям

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

• Никогда не ограничивайте максимальную длину пароля! А если уж ограничиваете, хотя бы сообщайте об этом пользователям. Одна из самых плохих практик, когда при создании аккаунта вроде бы можно указать пароль любой длины, но в реальности он обрезается до какого-то максимально допустимого количества символов, о котором пользователь не в курсе.
• Обязательно ограничивайте минимальную длину пароля. Причем лучше просить пользователей задавать действительно длинные пароли — хотя бы от 8 символов и выше. В идеале установить нижнюю планку на более серьезных значениях — 12 или даже 16 символов.
• Никогда не запрещайте использование каких-либо подмножеств символов. Если пользователю хочется использовать какие-нибудь экзотические закорючки — пусть он имеет такую возможность.
• Не ставьте слишком много условий. Лучше делайте упор на длину комбинации символов — это наиболее эффективный способ добиться того, чтобы пароль был действительно надежным.
• Давайте обратную связь при создании пароля в процессе регистрации аккаунта. Пользователю нужно понимать, почему его пароль не удовлетворяет принятой вами парольной политике.
• Не присылайте пароли в открытом виде по незащищенному каналу связи (читай: электронная почта), если вы генерируете их для пользователей на своей стороне. А вообще, лучше пусть пользователи делают это сами.
• И никогда-никогда не храните у себя их пароли. Вместо этого стоит использовать хеши, желательно соленые — кстати, на эту тему у нас есть развернутый пост.