19 смертных грехов, угрожающих безопасности программ
Шрифт:
Хотя в данном случае риск однократный, но этот пример иллюстрирует тот факт, что при проектировании многих базовых протоколов Интернет защите паролей не уделялось сколько–нибудь серьезного внимания. Считается допустимым, что почти все почтовые клиенты в мире отправляют по сети пароли для протоколов IMAP или POP в открытом виде. Даже при использовании шифрования принимающая сторона может увидеть незашифрованный пароль и что–то сделать с ним. Все широко используемые протоколы в этом отношении никуда не годятся, признать их хотя бы условно приемлемыми можно лишь, если пользователь защищает канал по протоколу SSL/TLS. Однако во многих случаях это не делается. Иногда пароли хранят в открытом виде, и редко когда прилагаются хоть какие–то усилия к тому, чтобы качество паролей было высоким.
Конечно, сеть Интернет проектировалась во времена, когда люди больше доверяли друг другу. Пароли – это средство
CVE–2005–0432
Это простой, документированный пример широко распространенной проблемы. Сервер BEA WebLogic версий 7 и 8 выдает разные сообщения об ошибках, когда вводится несуществующее имя пользователя и неправильный пароль. В результате противник, априорно не знающий имен пользователей, все же может отыскать действительные учетные записи и провести для них атаку полным перебором.
Ошибка в TENEX
Гораздо более известная утечка информации имела место в операционной системе TENEX. Когда пользователь хотел войти в систему, у него запрашивали имя и пароль. Проверка пароля производилась примерно так:
for i from 0 to len(typed_password):
if i >= len(actual_password) then return fail
if typed_password[i] != actual_password[i] then return fail
if i < len(actual_password) then return fail
return success
Противник мог угадать пароль, пробуя строки, размещенные в памяти на границе страниц. Если он хотел узнать, начинается ли пароль с буквы «а», то мог поместить строку «а» на одну страницу, а строку «ххх» – на другую. Если пароль действительно начинается с буквы «а», то произойдет отказ из–за отсутствия следующей страницы в памяти, в результате которого она будет загружена. Если же догадка ошибочна, то отказа не будет. Обычно задержка будет настолько маленькой, что для получения статистически значимого результата придется провести много испытаний. Но если пароль пересекает страницы и символ непосредственно перед границей угадан правильно, то время, затрачиваемое менеджером виртуальной памяти на загрузку отсутствующей страницы в память, настолько велико, что задержка видна невооруженным взглядом. Таким образом, для проведения атаки уже не нужно разбираться в математической статистике, достаточно знать этот фокус.
Но и не прибегая к страничному отказу, можно путем статистической обработки измеренного времени ответа добиться того же результата, только для этого придется автоматизировать тесты. Возможность подобной атаки – это одна из причин, по которой в хороших системах регистрации для обработки паролей применяются криптографические односторонние функции хэширования.
Кража у Пэрис Хилтон
В начала 2005 года во всех новостях прошел сюжет о том, что кто–то «хакнул» мобильный телефон модели T–Mobile Sidekick, принадлежащий актрисе Пэрис Хилтон, и опубликовал в Интернете все содержимое его памяти, включая контактные данные многих знаменитостей. На самом деле взломали не телефон. Архитектура Sidekick устроена так, что многие данные хранятся на сервере, так что владелец имеет к ним доступ как с телефона, так и из Web. Противник сумел взломать учетную запись актрисы и перекачать информацию через Web–интерфейс.
Как это могло случиться? Очевидно, противник каким–то образом узнал ее имя пользователя и зашел на сайт, заявляя, что он и является этим пользователем, но забыл свой пароль. Система была готова переустановить пароль, если получала правильный ответ на «личный вопрос», который запоминался при создании учетной записи. Если пользователь давал правильный ответ, то получал возможность сменить пароль.
Предположительно вопрос Хилтон был таким: «Кличка вашего домашнего любимца». Конечно, она выступала по телевидению вместе со своей собакой Tinkerbell, и противник это знал. Это и был правильный ответ, позволивший взломать ее учетную запись. Отсюда урок: персональную информацию, используемую для переустановки пароля, часто бывает легко получить. Лучше просто отправить новый пароль на почтовый адрес пользователя или, как в данном случае, на его мобильник в виде текстового сообщения. Хотя электронная почта – не самая безопасная среда, но для противника это дополнительная сложность, так как ему надо оказаться в таком месте, откуда можно организовать перехват почты. Это возможно, если противник имеет доступ к локальной сети, в которой жертва читает свою почту, но Хилтон такая мера все же помогла бы.
Искупление греха
О, вы много чего можете сделать, так
что садитесь поудобнее! И приготовьтесь слушать.Многофакторная аутентификация
Некоторые специалисты по информационной безопасности любят говорить, что парольные технологии умерли и что пользоваться ими вообще не нужно. На деле верно прямо противоположное. Есть три основных класса технологий аутентификации:
□ Что вы знаете. Сюда относятся ПИНы, парольные фразы, в общем, все, что можно охарактеризовать как пароль.
□ Чем вы обладаете. Речь идет о смарт–картах, криптографических маркерах, кредитной карте и т. д.
□ Чем вы являетесь. Это различные виды биометрии.
У каждого подхода есть свои плюсы и минусы. Например, физический предмет, на основе которого производится аутентификация, может быть утерян или украден. Биометрические данные можно похитить и фальсифицировать (например, с помощью искусственного пальца или путем внедрения битов, описывающих отпечатки пальцев, непосредственно в систему). А если ваши биометрические данные похищены, то это катастрофа – ведь изменить–то их вы не сможете!
Можно усилить аутентификацию, объединив все три технологии. Если противник похитит физический предмет, то ему еще предстоит узнать пароль. И даже если беспечная жертва оставит свой пароль под клавиатурой, противнику все же придется преодолеть барьер физического устройства аутентификации.
Подчеркнем, что защита системы усилится, лишь если вы будете учитывать при аутентификации разные факторы. Если же она построена по принципу «или–или», то противнику нужно взломать только самое слабое звено.
Хранение и проверка паролей
Пароли следует хранить в свернутом виде, то есть после применения к ним односторонней функции хэширования, не допускающей обращения. Тогда противник не сможет расшифровать пароль, а вынужден будет пробовать разные комбинации символов, пока не получится тот же результат хэширования. Поэтому нужно сделать все возможное, чтобы усложнить функцию нахождения соответствия.
Стандартный и надежный способ дает алгоритм PBKDF2 (password–based key derivation function, Version 2.0 – функция выработки ключа на основе пароля, версия 2.0). Он описан в документе Public Key Cryptography Standard # 5 (PRCS #5–стандарт криптографии с открытым ключом). Хотя первоначально эта функция разрабатывалась для создания криптографического ключа из пароля, но она хороша и для наших целей, поскольку является стандартной, открытой и удовлетворяет всем выдвинутым требованиям. Она односторонняя, но детерминированная. Можно задать размер результата, так что выбирайте валидаторы длиной не менее 128 битов (16 байтов).
У этой функции есть также особенности, затрудняющие атаку полным перебором. Во–первых, необходимо задать затравку, в качестве которой выбирается случайное значение. Это защищает от атак с предварительным вычислением. Затравка необходима для проверки пароля, поэтому можно хранить ее в составе результата, возвращаемого алгоритмом PBKDF2. Восьмибайтовой затравки достаточно, если она выбрана действительно случайно (см. грех 18).
Во–вторых, можно сделать так, что вычисление результата будет занимать относительно много времени. Идея в том, что законный пользователь введет пароль лишь один раз, так что вполне может подождать одну секунду, пока он будет проверяться. Но если противнику придется ждать одну секунду для каждого варианта, то офлайновая атака с перебором по словарю окажется весьма проблематичной. Управлять временем вычисления можно, задав счетчик итераций, определяющий, сколько раз повторять вызов основной функции. Возникает вопрос: «Так сколько итераций задавать?» Ответ зависит от того, сколько времени вы согласны ждать при использовании самой дешевой из имеющейся у вас аппаратуры. Если алгоритм реализован внутри недорого встраиваемого устройства, то 5000 итераций достаточно (в предположении, что он написан на С или машинном языке; желательно, чтобы алгоритм был реализован максимально эффективно, тогда вы сможете задать большее число итераций). Десять тысяч считается приемлемым значением счетчика в общем случае, если речь не идет о низкопроизводительном встраиваемом оборудовании или машинах 15–летней давности. На современных ПК (класса Pentium 4 и сравнимых с ним) можно говорить о 50–100 тысячах итераций. Чем число меньше, тем проще задача противника. Ведь он–то не ограничен встраиваемым устройством. Конечно, если вы зададите слишком много итераций, а приложение выполняет много операций аутентификации, то его производительность может пострадать. Поэтому начните с высокого значения и займитесь измерениями; не считайте при этом, что единственная причина медленной работы приложения – это большое число итераций.