Про пароли
arkanoid — 03.08.2011 да, меня это беспокоит и я хочу об этом поговорить.Пароли -- удивительно живучая штука, хотя неминуемую смерть им предсказывают последние 15 лет. Да-да, самые идиотские "повторно используемые" пароли. Где-то прижились "токены-калькуляторы" для аутентификации (особенно в ДБО), где-то используются смарткарты или usb-токены с pkcs#11 (хотя мудаки-производители за последние года три сделали ВСЕ, чтобы это уже почти рабочее решение ВНЕЗАПНО дохло, глючило, было несовместимо само с собой ни к чорту не годилось), публичные онлайн-сервисы активно используют SMS-авторизацию и аутентификацию, но основным и самым распространенным методом по-прежнему являются эти чортовы пароли. Все остальное внедрено крайне "точечно", включая софт-токены, которые, казалось бы, доступны в любом мобильном телефоне, достаточно просто интегрируются с чем угодно, худо-бедно стандартизованы -- но им, например, по популярности далеко не только что до паролей, а даже до мудацкого SecurID, который, к тому же, требует бессмысленного аппаратного сервера, в котором основная "аппаратная" часть -- независимые часы, извините (и бэкдор в подарок). Ну неудобно людям, что делать. Все "одноразовые" аутентификаторы плохо вписываются в системы single sign-on, к тому же. Я не сказал "совсем не вписываются", но плохо же.
Проблема же с паролями в том, что компьютеры стали быстрыми, каналы тоже, а человеческие мозги остались все те же. И сгенерировать и запомнить разумное количество энтропии, которое компьютер не подберет, стало часто малореально.
Какие практические выводы последних лет? Если у вас сперли хэши без соли или с ненормально короткой солью (два символа, например), значит, у вас сперли примерно 60-90% паролей, которые вскроются в пределах минут, максимум -- часов, хоть расшибись в лепешку, убеждая пользователя придумывать сложные пароли. Я хуже скажу, на добрую половину паролей, которые вскрываются несмотря на "сознательность" пользователя (бывает специфическая выборка таки действительно сознательных пользователей), никогда в жизни не подумаешь, посмотрев глазами, что это "плохой" пароль. Если ломать по радужным таблицам не получится, но доступен другой метод, который упирается в офлайновый криптографический перебор, процент упадет раза в два и придется повозиться. Но в любом случае, вас трахнули. [1]
Думаете, фраза как пароль сильно лучше? Да уже больше 15 лет назад было известно, что и тут не без проблем. [2]
Откуда вообще берутся парольные политики? Ну вот это все про буковки в разных регистрах, спецсиволы и так далее -- кроме "общих соображений", что мы имеем? Имеем мы NIST Special Publication SP800-63 [3], которая пытается наложить количественные метрики энтропии на эти ухищрения. Отсюда имеем специальную табличку, которая переводит буковки в эффективные биты:
первый символ -- 4 бита,
следующие семь -- по два,
до двадцатого -- полтора
дальше -- один,
+6 бит "бонус" если требуются спецсимволы и верхний регистр,
+6 бит "бонус" если была проверка на словарные соответствия.
Так вот, есть душевнополезное чтиво [4], где Кэп нам рассказывает, что все это полнейшая лажа (что знает каждый школьник-кун, который действительно пробовал ломать пароли). То есть не то что там циферки неправильные или еще что, а просто сам подход оценки лажа от начала и до конца. Статья посвящена подбору в онлайне, который ограничен десятками тысяч попыток, потому что с офлайновым подбором мы уже в заднице изначально. Рассчет с энтропией рисует нам линейную зависимость процента подбора от числа попыток (что очевидная чушь из общих сообращений). Реальный график над этой прямой сначала взлетает, потом уходит заметно ниже. Пересечение зависит от используемой парольной политики и находится в районе нескольких тысяч попыток, что на практике означает, что если мы (ну, они, зхлохакеры) прошли некоторый начальный пик, то дальше имеет смысл переходить к следующей цели. Там еще много всяких любопытных данных, однако с практической точки зрения интересно, что "выпрямить" кривую позволяет только серьезный блэклистинг по словарю, и все равно, хоть тресни, почти один процент паролей останется слабым (они подберутся менее, чем за 4096 попыток), что с точки зрения того же NIST ни к чорту не годится. Остальные методы небесполезны, но толком не спасают.
Вообще интересующимся темой я крайне рекомендую таки прочитать полную статью, она небольшая и довольно познавательная, некоторые способы решения там предлагаются и анализируются.
Ну и что такое в наше время разумная парольная политика?
Мои соображения следующие:
Оптимальное время жизни пароля -- от полугода до года. Меньший срок приводит к нервической фрустрации и бумажкам на мониторе или под клавиатурой. Больший срок плох не потому, что кто-то будет сидеть и ломать один пароль годами, а потому, что в реальном мире управление жизненным циклом данных всегда может дать сбой и что-то может утечь потому что "кто будет следить за всем этим старьем", и не думайте, что к вам это не относится.
Единственное средство энфорсить сильные пароли -- превентивно пытаться их взломать. Ну хоть как-то, минимальными ресурсами. Все остальное -- не работает совсем или почти совсем.
Автоматическая генерация "произносимых" и "запоминаемых" паролей приводит или к слишком слабым, или к непроизносимым и незапоминаемым результатам. У них есть один плюс, хотя и сомнительный -- в отличие от сочиненных людьми, они действительно содержат гарантированное, пусть и недостаточное, количество энтропии, что при условии наличия какой-никакой защиты от перебора делает это решение оптимальным.
Intruder lockout в том или ином виде должен быть. Что неминуемо ведет к угрозе атаки на отказ в обслуживании. На этот случай хорошо иметь механизм разблокировки по независимому аутентификатору, ну как PUK на телефоне.
Кстати, типична ситуация, когда защита от перебора паролей делается на уровне приложения, а не сервера аутентификации, что приводит к традиционным граблям: на веб-морде, скажем, она есть, а можно подключиться почтовым протоколом и там ее нет, а пароли те же самые.
И все-таки, если есть возможность избавляться от паролей в качестве единственного фактора аутентификации, надо им пользоваться. Что угодно плюс пароль лучше, чем просто пароль, так ведь?
[1] Luke StClair et al. Password Exhaustion: Predicting the End of Password Usefulness http://nsrc.cse.psu.edu/tech_report/NAS-TR-0030-2006.pdf
[2] Arnold G. Reinhold Results of a Survey on PGP Pass Phrase Usage http://world.std.com/~reinhold/passphrase.survey.asc
[3] NIST Special Publication 800-63 http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
[4] Matt Weir et al. CCS 2010 Presentation: Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords http://sites.google.com/site/reusablesec/Home/presentations-and-papers/CCS_Password_Metric_Measurement.pdf