19 смертных грехов, угрожающих безопасности программ

Виега Джон

В общем и целом это, может быть, и не самый большой риск в системе, но нельзя не признать, что существуют более эффективные способы переустановить пароль. Неплохая альтернатива – это метод «секретного вопроса», но понадобится довольно внушительный перечень необычных вопросов. А узнать девичью фамилию матери жертвы совсем нетрудно. Другой пример: поклонники телевизионных реалити–шоу узнали кличку домашнего любимца Пэрис Хилтон, и, наверное, именно так кто–то взломал ее учетную запись на сайте T–Mobile.

Протокол E*Trade

Первоначально данные шифровались в этом протоколе путем выполнения XOR с фиксированным значением.

Легко реализовать, но столь же легко и взломать. Даже любитель сможет понять, что происходит, собрав и проанализировав достаточный объем данных, передаваемых по сети. Не займет много времени вычислить так называемый «ключ шифра», после чего вся схема оказывается вскрытой. И что еще хуже, в этой схеме даже не делается попытки реализовать аутентификацию сообщений в ходе сеанса, поэтому опытный противник сможет провести практически любую из упомянутых в этой главе атак.

Искупление греха

Вообще говоря, мы рекомендуем шифровать весь сетевой трафик по протоколу SSL/TLS, если это возможно. Можно также пользоваться такими системами, как Kerberos. Если вы решите остановиться на SSL, прислушайтесь к нашим советам в грехе 10. Иногда люди не ожидают, что в их сеть будет встроен SSL, особенно если пользуются программами, которые этот протокол не поддерживают. Но существуют SSL–прокси, например Stunnel. Избежать такого рода проблем можно также, развернув IPSec или иную технологию организации VPN.

Иногда включить SSL/TLS не представляется возможным. Например, если вы вынуждены обмениваться данными с не контролируемыми вами серверами или клиентами, которые не поддерживают эти протоколы. В таком случае вам решать, идти на риск или нет.

Другая причина отказа от SSL/TLS заключается в желании избежать накладных расходов на аутентификацию. В SSL применяется криптография с открытыми ключами, которая обходится довольно дорого и потенциально способна привести к отказу от обслуживания. Если это действительно серьезная проблема, то существуют решения на уровне сети в целом, например балансирование нагрузки.

Рекомендации низкого уровня

Ладно, вы не хотите последовать нашей рекомендации и воспользоваться высокоуровневой абстракцией типа SSL/TLS или Kerberos. Вернемся к базовым сервисам сетевой безопасности: конфиденциальности, начальной и последующей аутентификации.

Самое важное, что должен защитить механизм обеспечения конфиденциальности, – это аутентификационные данные. Хороший протокол аутентификации содержит собственные средства защиты, но самые распространенные протоколы к числу хороших не относятся. Вот почему аутентификация на основе пароля с применением SSL/TLS обычно применяется только для аутентификации клиента и производится по зашифрованному каналу, хотелось бы думать, что после того, как клиент аутентифицировал сервер (тем самым гарантируется, что удостоверяющая информация останется надежно защищенной в сети).

Но настроить эти сервисы безопасности непросто. И для начальной, и для последующей аутентификации нужно обеспечить защиту от атаки путем воспроизведения, а для этого необходимо какое–то доказательство «свежести». Обычно для решения этой проблемы в протоколах начальной аутентификации применяется трехфазная схема «оклик–отзыв». Ни в коем случае не пытайтесь спроектировать собственный протокол начальной аутентификации, поскольку тут есть очень тонкие проблемы, с которыми

по силам справиться только опытному криптографу. Да даже и в этом случае проблемы иногда остаются!

В протоколах аутентификации в ходе сеанса обычно для предотвращения атак с воспроизведением используется счетчик сообщений. Часто он является частью входных данных для алгоритма аутентификации сообщений (а это, кстати, может быть и сам алгоритм шифрования), но иногда оказывается частью данных. Главное, что принимающая сторона должна иметь возможность отвергать сообщения, приходящие не по порядку. Для протоколов без соединения это может оказаться невозможным. Поэтому принято использовать окна счетчиков сообщений: в пределах окна обнаруживаются дубликаты, а если счетчик оказывается вне окна, сообщение отвергается.

Кроме того, механизм как начальной, так и последующей аутентификации может стать причиной отказа от обслуживания, если в них применяется криптография с открытым ключом. Например, если вы снабжаете отдельные сообщения PGP–подписью, то противник может без ощутимых затрат послать вам множество сообщений с некорректными подписями и тем самым «подвесить» процессор. А если работает какой–то механизм ограничения пропускной способности, то может оказаться заблокированным законный трафик.

Гораздо лучше как можно скорее переходить к шифрованию с секретным ключом. Так, в SSL/TLS есть режим кэширования сеансов, в котором соединения аутентифицируются с помощью симметричного шифрования после того, как один раз были аутентифицированы с помощью более накладного механизма.

Еще одна тонкость при использовании криптографии с открытым ключом для аутентификации сообщений заключается в том, что при этом невозможно скрыть личность отправителя, и потенциально это может служить доказательством в суде (это называется «неотрицаемость»). Отправитель не может заявить, что он не посылал сообщение, под которым стоит его цифровая подпись. Правда, не исключено, что в будущем отговорки типа «я этого не делал, кто–то влез в мой компьютер или заслал вирус» будут приниматься, что обесценивает идею неотрицаемос–ти. В общем случае лучше, наверное, избегать применения цифровой подписи для аутентификации сообщений и не только из–за вычислительной сложности криптографических алгоритмов, но и чтобы оставить шанс на отрицание своего авторства, если, конечно, противное не оговорено явно в законе. Пользователи оценят отсутствие механизма, по которому их можно было бы привлечь к ответственности за случайно оброненное слово, неправильно понятую шутку и цитаты, вырванные из контекста.

У сервиса конфиденциальности тоже есть свои тонкости, одни из них – криптографического, другие – практического характера. Например, иногда небезопасно параллельно шифровать и аутентифицировать одни и те же данные или даже шифровать уже аутентифицированные данные. Единственная общая безопасная стратегия состоит в том, чтобы сначала шифровать данные, а потом уже аутентифицировать. Если конфиденциальность не слишком важна, то можно аутентифицировать незашифрованные данные.

Заметим еще, что популярные механизмы обеспечения конфиденциальности часто применяются неправильно, поскольку разработчик не понимает, при каких условиях они безопасны. Так, сплошь и рядом некорректно используют блочные шифры в режиме СВС (сцепление блоков шифртекста) и алгоритм RC4.