Безопасность сетевых протоколов

ЗАРАЗА

Спецвыпуск: Хакер, номер #058, стр. 058-084-6

Аутентификации по Challenge-Response (запрос-ответ) с помощью стандартных хэш-функций

К этим методам можно отнести APOP, AUTH CRAM-MD5 и Digest в HTTP, реже используются другие CRAM-методы, например CRAM-MD4 и CRAM-SHA1. При использовании такой аутентификации пароль пользователя никогда не попадает в провода. Причем даже криптографические проблемы SHA-1 или слабые генераторы случайных чисел при генерации challenge практически не сказываются на уровне защиты пароля. Однако следует помнить, что Challenge-Response не защищает от атак на подбор слабых паролей (bruteforce), если пароль короткий или подбирается по словарю.

Встроенная аутентификация Windows

Это AUTH NTLM и аутентификации NTLM и Negotiate в HTTP. В Outlook Express встроенная аутентификация NTLM называется SPA (Secure Password Authentication). Недостатки такой аутентификации:

1. Ее прозрачность (при такой аутентификации сначала пробуется имя и пароль, с которыми осуществлен вход в систему).

2. Невозможность подключиться к одному и тому же серверу с несколькими учетными записями (относится ко многим версиям Windows).

3. Возможность атак релеинга аутентификации в случае NTLM.

Об этом классе атак и других особенностях и недостатках NTLM подробно рассказывается в статье "NTLM и корпоративные сети" (www.security.nnov.ru/articles/ntlm). Использовать встроенную аутентификацию Windows (и в частности SPA) с недоверенными серверами ни в коем случае нельзя!

Аутентификация Kerberos

Это AUTH GSSAPI и http-аутентификация Negotiate. Kerberos - единственная аутентификация, при которой в процессе аутентификации проверяется IP-адрес клиента и сервера. Это защищает (разумеется, при полной и правильной реализации Kerberos) от атак релеинга и подмены сервера, от которых не спасают все прочие виды аутентификации. К сожалению, из-за своей достаточно сложной топологии в Сети Kerberos практически неприменим, и он используется преимущественно в корпоративных сетях, так как подобную аутентификацию сложно использовать через NAT или прокси.

Во многих случаях клиентское приложение самостоятельно выбирает наиболее "мощный" протокол аутентификации. Так поступают, например, практически все клиенты HTTP (браузеры). Хотя бывают и досадные недоразумения, например в Mozilla Firefox (www.security.nnov.ru/Fnews19.html).

На первый взгляд, такое поведение вполне оправданно, но у него есть огромный недостаток: атакующий, который имеет возможность контролировать трафик между клиентом и сервером (активные атаки Man-in-the-Middle, например в случае подмены сервера или релеинга соединения), может "заставить" клиента переползти на более мягкий протокол аутентификации, вплоть до открытого текста.

Разумеется, после всего вышеперечисленного можно порекомендовать использовать в клиентском приложении Kerberos-аутентификацию либо, в случае если она недоступна, аутентификацию Challenge-Response.

Кроме того, все современные протоколы поддерживают TLS-версию (Transport Layer Security - протокол, поглотивший SSL). При условии что работа с сертификатами реализована некорректно, TLS обеспечивает надежную защиту данных от перехвата и подмены, а также взаимную аутентификацию клиента и сервера на основе сертификатов. Если есть такая возможность, TLS нужно внедрять и использовать.