Одним из самых ярких событий уходящего года для нас стала Yet another Conference 2012. В числе её участников был и Александр Песляк, более известный как Solar Designer.
Как многие знают, он — основатель проекта Openwall, автор свободного программного обеспечения (в том числе популярной программы для аудита безопасности паролей John the Ripper). Solar Designer был техническим рецензентом книги о компьютерной безопасности Silence on the Wire Михала Залевского и написал для нее предисловие.
С докладами о компьютерной безопасности Александр участвовал во многих международных конференциях — HAL2001, NordU, FOSDEM, CanSecWest, PHDays. На YaC 2012 он рассказывал «Как защитить миллионы паролей». Перед выступлением мы взяли у него небольшое интервью. Solar Designer рассказал, как стал специалистом по компьютерной безопасности и поделился своим взглядом на её современное состояние.
Скажу честно, когда я думал, с кем из докладчиков YaC поговорить дополнительно, приходил ко многим в Яндексе и задавал этот вопрос. Кто-то не знал тебя, а кто-то, увидев твою фамилию в числе докладчиков, сразу говорил: «Зови его! Как можно вообще думать, о чём с ним говорить!» Кажется, не все люди знают, чем ты занимаешься и только те, кто знает, понимают, как это интересно. Расскажи для начала, чем ты занимаешься и почему ты вообще рассказываешь на такую тему?
Можно начать очень издалека. Компьютерной безопасностью как хобби я начал заниматься ещё в 90-е. И потом это стало профессиональной деятельностью. Я разрабатывал свободный софт по этой тематике. Одной из подтем стали инструменты для обеспечения информационной безопасности, другой — программы общего назначения, но написанные с учётом повышенной безопасности. В частности POP3 Server, используемый в системе OpenBSD, которой пользуются некоторые интернет-провайдеры. Далее уже в рамках профессиональной работы и соответствующих потребностей клиентов встал вопрос защиты их пользователей. В частности паролей, потому что парольная аутентификация использовалась и в 90-е, и в нулевые, и используется сейчас. К ней добавилась многофакторная аутентификация, token-ы, но пароли всё равно остаются актуальными. И не только для аутентификации, но и для защиты конфиденциальной информации, шифрования файлов, зашифрованных файловых систем. В своём докладе на YaC я рассазывал именно о паролях для аутентификации на примере компаний, где количество пользователей исчисляется миллионами. Это задача, которая, с одной стороны, очень сложная. С другой, ограничившись такой её подобластью, я могу за 30-40 минут рассказать то, что, мне кажется, будет полезным для аудитории. В целом область парольной защиты слишком широкая и в один доклад её всю не уложить.
Понимаю, что невозможно за пару минут пересказать сорокаминутный доклад, но, может, поделишься хотя бы тезисно? Возможно, нас слушают те, кто не очень хорошо понимает, что именно скрывается за ним.
Я буду рассказывать об исследованиях недавних лет, начиная с 2009 года. Именно тогда Колин Персиваль, который до недавнего времени был security officer-ом проектов FreeBSD, предложил использовать для хэширования паролей так называемые memory hard functions. То есть криптографические хэш-функции, которые намеренно используют большие объемы оперативной памяти. Цель такого использования — повысить стоимость оборудования для подбора паролей. Получается, когда мы на обычном компьютере используем только центральный процессор, то для решения криптографических задач используется лишь незначительная часть площади кристалла. Соответственно при специализированных разработках для подбора паролей — вплоть до создания специализированных микросхем — получается, что у атакующего есть очень сильное преимущество. В механизме scrypt, разработанном Колином, в качестве атакующих рассматривались правительственные агентства. В примерах из моего доклада мы говорим в контексте парольной аутентифиации скорее о неправительственных злонамеренных источниках. К ним можно отнести тех, для кого взлом — это хобби, а можно говорить и о случайных утечках паролей. Если взять средние мировые данные, то еженедельно в какой-то крупной компании происходит утечка сотен тысяч, а бывает и миллионов паролей.
А почему плохи те функции для их хэширования, которые используются сейчас?
Они лишены этого свойства. Это одна из их особенностей, но есть ещё некоторые другие недостатки. В них недостаточно параллелизма. То есть из-за этого они не могут использоваться полностью современными процессорами, которые способны одновременно выполнять много задач. Их алгоритмы и код были разработаны в 90-е годы, а иногда и раньше. Разработка Колина Персиваля лишена этого недостатка. В ней есть один из трех параметров, который указывает желаемый объём параллелизма. В моём докладе я буду рассказывать, увы, и о недостатках его метода. Оказывается, внедрять его в компаниях с теми объёмами пользовательских баз, о которых в нём идёт речь, довольно сложно. Причина в том, что существуют довольно жёсткие требования по времени на одну произведённую аутентификацию. Очевидно, в первую очередь это связано с тем, сколько готов ждать пользователь. В исследованиях Колина предлагалось 100 миллисекунд. Другое ограничение — серверные ресурсы. Если большое количество пользователей — это бесплатные аккаунты, то компания не будет готова вкладывать большие деньги в их аутентификацию. Нужно снижать её себестоимость. Для компании масштабов Яндекса даже если мы ограничиваемся не 100 миллисекундами, а 10 или одной, всё равно нужно ставить кластер где-то из 10 серверов. В такой ситуации применение scrypt становится довольно сложным. И сложности связаны с тем, чтобы заполнить приличный объём оперативной памяти за одну миллисекунду. Просто заполнить её ещё можно, но у нас функция не должна упрощаться; размер области памяти, которая должна находиться в быстрой памяти, не должен убавляться. Чтобы обеспечить защиту от быстрого подбора, который быстрее, чем мы сами можем вычислять, нам приходится использовать медленную оперативную память и проводить над ней нетривиальные операции. И это не просто последовательные выполнение и чтение. И уложить это всё в одну миллисекунду оказывается довольно сложно.
Кажется, в первую очередь это актуально большим компаниям, которые работают с особенно ценными знаниями. А что делать ещё более массовым — условно вроде Яндекса, — пользователям которых будет лучше, если они потратят свои ресурсы на какие-то другие разработки? Есть ли для них какие-то альтернативы?
В моём докладе я как раз говорю об этом. Уровень в одну миллисекунду уже компромисс: хотелось бы сто, но мы готовы снизиться вплоть до одной.
И при этом всё равно возможно использовать scrypt?
При этом тоже есть сложности scrypt: следует найти его модификации. Я предлагаю две. Помимо этого рассматриваю установку дополнительного оборудования, которое предотвращает подбор паролей по полностью украденной базе данных. И если украден секретный ключ — так называемый локальный параметр, — хранящийся в этом дополнительном оборудовании тоже.
Это похоже на соль или это что-то другое?
Да, похоже на соль. Некоторые называют это второй солью, некоторые — перцем. Но он будет закодирован в аппаратном устройстве. Это может быть обычный сервис. Просто это значит, что у нас есть одна линейка серверов с аутентификацией, за а ней — второй ряд с серверами хэширрования паролей. То есть сервера с аутентификацией и хэшированием паролей разносятся. В результате у серверов хэширования паролей гораздо меньше возможных векторов атак на них, потому что они предоставляют очень простой интерфейс: им передаётся пароль — они возвращают хэш. В простейшем случае. Поэтому их становится сложнее взломать и они обеспечивают дополнительный уровень защиты, потому что не доступны напрямую с остальных сервисов компании. В то время как серверы с аутентификацией доступны с таких сервисов, как веб-почта, например.
Поэтому должны быть изолированы?
Да, недоступность должна быть обеспечена либо физическими кабелями, либо криптографическим протоколом, если это через туннель какой-то там внутри компании.
Какие вопросы безопасности тебе кажутся важными, но недооценёнными?
В целом, в этой области мало что изменилось с нулевых годов, с 90-х, а может быть, и с более ранних. Это связано с существующими в целом компромиссами в самых разных областях. В некоторых случаях безопасность противопоставляется удобству пользователя, в других — коммерческой выгоде компаний. Из-за этого получается, что многое в вопросах безопасности недооцененно.
На мой взгляд, во многих областях можно находить более правильные компромиссы, чем те, к которым на данный момент пришла индустрия. Сложность устройств растёт, сложность программ растёт, и, соотвественно, растёт количество уязвимостей. Правда, не так быстро, потому что одновременно совершенствуются техники их поиска и устранения. Крупные компании вроде Microsoft уже в процесс разработки стали включать аспекты, связанные с безопасностью. Даже соответствующие термины появились. SDLC, например. Сложность устройств, которые могут пользоваться спросом, можно бы было ограничить. Но частично она связана с тем, что когда растёт количество пользователей компьютерной техники и интернет-пользоватлей, приходят новые люди, которые далеки от компьютеров. И это хорошо. Получается, что они не знают, чего ожидать, что просить у производителей и за что голосовать рублём. Они покупают устройства, которые могут быть красивее и сложнее, но не рассматривают простые альтернативы, которые могут быть безопасней. Соответственно, у производителей нет мотивации делать простые и безопасные устройства. Подобная проблема существует, но я не могу сказать, как её решить, потому что она достаточно фундаментальна и связана с тем, что в обществе происходит. И в общем-то это хорошие процессы.
С одной стороны, это хорошие процессы. С другой, понятно, что на каком-то уровне они будут приводить к каким-то серьезным последствиям, которые, возможно, повернут их в обратную сторону.
Да, например, мало кто знает о том, какие риски таят в себе мобильные устройства и как их учитывать, а пользуется ими каждый. Получается, что все мы в чём-то уязвимы. И с этим мало что можно поделать, а в ближайшие годы ситуация, скорее всего, будет только ухудшаться.
Но это такой пользовательский уровень, а на чуть более высоком? Например, осознания проблем в индустрии. Что, на твой взгляд, там происходит или не происходит важного. Тоже ничего не меняется с 90-годов?
Очень сильно усовершенствовались технологии поиска уязвимостей как в программном коде, так и в исходном и бинарном. Компания Veracode сделала сейчас впечатляющие механизмы анализа бинарного кода. Очень впечатляющий результат. То, как они анализировали бинарный код, способно сравниться с тем, как конкуренты анализируют их исходный код, чтобы найти уязвимости для их заказчиков. Соответственно, заказчики, которые до сих пор не решались предоставить исходный код на аудит сторонней компании, получили возможность предосталять бинарный. Он скомпилирован специальным образом, там отключается оптимизация и влючается отладочная информация. Не только нэйтив для процессоров, там JavaWide код можно давать. Компания Veracode очень успешна в этом плане. Можно сказать, что на её счету достижения последних нескольких лет.
В каких случаях полезней изучать что-то скомпилированное, а не исходный код, когда всё равно есть возможность изучить и его даже без какой-либо специальной оптимизации?
Оба варианта актуальны при наличии и той, и другой возможности. При анализе только исходного кода получается, что мы вынуждены использовать либо компиляты, фактически аналогичные тем, которыми мы обычно компилируем программу для ее распространения и использования по назначению. Либо мы используем статический анализатор, который имеет свой парсер языка высокого уровня и другие собственные компоненты, и будет отличаться от компилятора. В частности, он привнесет некоторые искажения.
Но компиляторы, в которых отключена оптимизация, тоже будут отличаться.
Да, есть такой недостаток. Почему надо отключить оптимизацию? Это связано с затратами компьютерных ресурсов на анализ этого бинарного кода. Там довольно сложный их алгоритм. Я общался с сотрудниками Veracode на эту тему. Получается, что если оптимизация включена, компилятор настолько агрессивно использует регистр процессов, которые перемещают одну и ту же переменную в регистре в пределах одной функции, то сложности в процессе растут по экспоненте. В принципе, за большую стоимость можно проанализировать, а если проект небольшой, можно оптимизировать и проанализировать точно так же. А отладочная информация нужна для того, чтобы в отчёте была ссылка на исходники, номера строк, идентификаторы. Удобство в этом вопросе тоже очень важно, потому что отчёты большие и если они неудобные, то становятся бессмысленными.
Автор: anton
