Как не надо писать парольную политику

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

Эпилог

Как то так произошло, что в один день мне пришлось поменять пароли в Вконтакте, QIWI и Билайне. И каждый раз я наталкивался на очередную глупость: Вконтакте сообщил мне, что мой пароль скомпрометирован (КАК?? Я год не заходил в свой аккаунт!) и потребовал сгенерировать новый и уникальный. QIWI захотел, чтобы я менял свой пароль каждый месяц (!), и я задолбался на каждый клик мыши вводить проверочный код из СМС.

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

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

РИСК (утрата аккаунта) < УСИЛИЕ(запоминание уникального пароля)

Да и зачем драконить пользователя, если в большинстве случаев эти меры, как металлодетекторы на вокзале - абсолютно бесполезны?

Модель угроз

А зачем вообще нужны сложные пароли? И кто должен их защищать и от чего?

Очевидно, что пароль могут: а) украсть, б) подобрать.

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

Таким образом парольная политика должна защищать от трех угроз:

1. угроза подбора пароля;

2. угроза кражи пароля со стороны пользователя (к примеру, кейлогер);

3. угроза взлома сервера и кражи базы данных паролей.

Подбор пароля

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

Кража пароля со стороны клиента

Наиболее эффективной контрмерой в этом случае является применение методов двухфакторной аутентификации. Тогда если вероятность взлома пароля, к примеру, будет 0.01, и вероятность перехвата СМС с кодом будет тоже 0.01, то итоговая вероятность взлома обоих факторов будет 0.01*0.01 = 10^(-4)

Примечательно, что если вы, к примеру, будете использовать простой пароль с вероятностью подбора 0.99, то этот пароль окажется более стойким в связке с вторым фактором (0.01*0.99=0.0099), чем сложный и комплексный пароль, но без СМС (0.01 > 0.0099).

Вывод1: очень сложный и очень простой пароли одинаково уязвимы к атакам со стороны клиента (кейлогер, троян и т.д.);

Вывод2: если используется второй фактор - пароль может быть "слабее" в той степени, в которой второй фактор "надежнее".

Взлом сервера

Взлом сервера - это опять таки проблема сервера, а не клиента. 

Традиционно пароли хранятся в виде хэшей sha256, которые сегодня подбираются домашними компьютерами со скоростями порядка нескольких миллиардов хэшей в секунду. 

Итоговая стойкость пароля прямо пропорциональна алфавиту и длине пароля, и обратно пропорциональна скорости перебора.

Таким образом если сервер будет использовать более сложную и адаптированную для хранения паролей функцию хэширования Scrypt, то скорость подбора уменьшиться примерно в 1000 раз => сложность пароля возрастет в ту же 1000 раз.

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

(26*2+10)^8 = 2 * 10^14

(26+10)^8 * 10^3 = 2.8 * 10^15

Вывод: вместо того, чтобы заставлять пользователя использовать заглавные буквы и спецсимволы - усиль алгоритм хэширования!

Расширение алфавита пароля направлено так же на противодействие брутфорсу. Однако и здесь надо понимать, что, к примеру, 10 символьный пароль, составленный из строчных английских букв и цифр, в 10 раз надежней, чем 8 символьный пароль, составленный их строчных и заглавных букв и цифр.

(26*2+10)^8 = 2 * 10^14

(26+10)^10 = 3.6 * 10^15

То есть увеличение алфавита практически в два раза оказалось менее эффективным, чем увеличение длины пароля на 2 символа!

Вывод: вместо того, чтобы требовать заглавные буквы и спецсимволы - требуй более длинный пароль!

Еще одной проблемой является срок действия пароля. Я вот искренне не понимаю, зачем он вообще нужен. Если сервер взломают, похитят хэши и начнут их ломать, то большая часть слабых хэшей будет подобрана в течении нескольких часов или дней. Именно так было с LinkedIn, eHarmony, LastFM и другими. Какой злоумышленник будет ломать хэши месяцами? Тот, которому нечем занять свой суперкомпьютер и у которого халявное электричество, по всей видимости..

И все таки главная проблема с паролями - это их запоминание. Чем сложнее пароль - тем труднее пользователю его запомнить. Поэтому пользователь решает эту проблему двумя способами:

1. Пользователь использует одинаковые сложные пароли на разных сайтах. 

Это очень серьезная проблема, которая дает козыри злоумышленникам и ликвидирует все плюсы комплексных паролей. Украв пароль пользователя на одном сайте, злоумышленник будет знать пароль пользователя к остальным сервисам. 

2. Пользователь начинает записывать свои пароли.

Это так же очень плохо. Записанные пароли легче потерять, дольше вводить и легче подсмотреть. Пользователь так же может доверить свои пароли таким сервисам, как LastPass. В случае компрометации серверов LastPass, пользователь потеряет все и сразу.

Поэтому хорошая политика безопасности будет обязательно искать компромисс между техническими возможностями сервиса и требованиями к длине и сложности пароля. Хорошая политика обязательно будет учитывать то, что пароль должен крепко сидеть в голове пользователя, а не существовать "в вакууме" в виде псевдослучайной не читаемой последовательности символов. И самое главное - парольная политика не должна лишать пользователя права на самостоятельный выбор пароля!

Что еще почитать?

• Вредные советы про пароли
• Как безопасно использовать один пароль на всех сайтах