Страницы

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


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

Эпилог


Как то так произошло, что в один день мне пришлось поменять пароли в Вконтакте, 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, пользователь потеряет все и сразу.

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


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



18 комментариев:

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

    ОтветитьУдалить
    Ответы
    1. Учтены! Генерируя для каждого пароля новую соль, которую можно записывать прямо рядом с хэшем пароля, выигрыш во времени от радужных таблиц можно свести к 0.

      Радужные таблицы работают только там, где соль жестко задана разработчиком сервиса.

      Длинные простые пароли с проверкой по базам - то что надо!

      Удалить
  2. Про срок действия паролей правда не понимаете?
    Это не к серверной части относится и не к направленным атакам, а к "обычной" деятельности троянов на клиентских машинах. Обычно воруют пароли у пользователей троянами одни люди, затем продают логи наворованного другим людям, эти другие люди логи сортируют, и (в лучшем случае они же, а скорее всего тут тоже этап продажи сортированных результатов) готовят и реализуют непосредственную атаку например с выводом денег куда либо.
    Вот на эти моменты (сбор, продажа, сортировка, [продажа,] подготовка, реализация) как правило требуется несколько месяцев. Если пользователь за это время сменит пароль, всё пропало :)

    ОтветитьУдалить
    Ответы
    1. Правда не понимаю :)

      Крупнейшая торговая сеть Target узнала о взломе своей базы после того, как в андерграунде стали продавать миллионы кредитных карт, украденных у Target (http://krebsonsecurity.com/2013/12/cards-stolen-in-target-breach-flood-underground-markets/). Так же было с LinkedIn. Частенько специалисты сервиса узнают о взломе своего сервиса или из новостей, или от банка.

      В реальности взлом+слив+продажа+обналичка занимают не более недели. А если о взломе стало известно - то часы.

      Удалить
    2. Еще раз - речь идёт не о взломе сервера, а о сборе данных троянами у пользователей.

      Удалить
    3. Намного проще продавать самих пользователей с троянами и оперативно получать все пароли через админку ботнета.

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

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

    ОтветитьУдалить
    Ответы
    1. Менеджер паролей с маcтер-паролем - это и есть LastPass (или аналоги) - частный случай 2 способа.

      Не догадаюсь :)

      Удалить
    2. Берётся сложный пароль, к нему добавляется кусок из названия сайта определённой длины. Например, первые три символа. Тогда для каждого сайта пароль будет разный, и в каждом отдельно взятом сайте - очень сложный. Хэши уж совсем разные. Можно усложнить эту схему, не буду уж совсем разжевывать секреты выдавать)

      И кстати есть ещё и пятый вариант, но он не для всех :)

      Удалить
    3. Думаю что я смогу угадать Ваш сайт и Ваш настоящий пароль с первых трёх букв украденного пароля с вероятностью 95% ;)

      Pwdhash делает это профессионально. Почитайте про этот плагин. Линк есть в конце статьи.

      Удалить
    4. нука допустим 35#482o9gsf5zc это пароль к почте мейл.ру, какой будет к гуглу? Не угадаете вы в 100% случаев по одному паролю, в лучшем случае угадаете с вероятностью процентов 5 если будете знать 100 паролей. Я же вам принцип рассказал, а не готовую систему.

      Pwdhash это как раз частный случай №3, т.е. менеджер паролей - пароля вы не знаете, знаете мастер пароль.

      Удалить
  4. Срок действия пароля нужен для ограничения по времени несанкционированного доступа под скомпрометированной учётной записью. Враг подсмотрел пароль пользователя и ведёт пассивное наблюдение, например, знакомится с документацией или просматривает электронную почту. Определить это можно по журналам подключения (IP компьютера при подключении к почтовому ящику), но если таких подключений много? Регулярная смена пароля позволяет исключить подобные использования доступа.

    ОтветитьУдалить
    Ответы
    1. Регулярная смена пароля не исключит этот сценарий, а лишь уменьшит временное окно атаки до 1 месяца (при самом плохом для злоумышленника раскладе).
      Такое "время реагирования" на атаку абсолютно не приемлемо сегодня.

      А что мы будем делать, когда повсюду будут биометрические системы аутентификации? Менять пальцы и глаза раз в полгода?

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

      Удалить
  5. только от случайной компрометации больше ничего или компрометации недобросовестными коллегами.

    ОтветитьУдалить