без лишних глаз

3APA3A (WWW.SECURITY.NNOV.RU)

Спецвыпуск: Хакер, номер #072, стр. 072-092-4

Как видим, во второй части используются только контексты, но не сам ключ.

Сеанс аутентификации CRAM-MD5 выглядит примерно так:

<<+OK 3APA3A/POP3-3.0-beta <8231.1158097553@mail.example.com>

>>AUTH CRAM-MD5

<<+ PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+

>>dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

<<+OK Authenticated

После команды AUTH следует Challenge сервера, который генерируется так же, как и для APOP, но передается в Base64. Так же в Base64 передается и ответ.

К сожалению, возможность избавиться от хранения пароля в открытом тексте не даст нам слишком много с точки зрения безопасности, так как мы будем вынуждены хранить контексты MD5, которые точно так же могут быть использованы атакующим. Правда, только для аутентификации по CRAM-MD5.

Именно CRAM-MD5 стал стандартом почтовой аутентификации, - прочие CRAM-методы применяются крайне редко.

На этом распространенные стандартные протоколы аутентификации для получения почты заканчиваются. Можно встретить еще DIGEST-MD5 (усовершенствованная версия CRAM-MD5, чаще применяемая для аутентификации доступа к веб-серверам) и Kerberos, но на практике они используются очень редко.

[NTLM.]

Стоит поговорить и о нестандартных. Отличился, разумеется, Microsoft. Почтовый сервер Microsoft (то есть Exchange) должен интегрироваться в доменную структуру и Active Directory и использовать доменные пароли. Использовать для аутентификации доступа APOP или CRAM-MD5 невозможно, так как по умолчанию пароль не хранится в открытом тексте, а хранится в виде NT-ключа (и, если не запрещено, LM-ключа), который невозможно использовать ни в одном из почтовых протоколов аутентификации, за исключением открытого текста. Поэтому для протокола POP3 в Microsoft Exchange и Outlook Express был реализован протокол NTLM. Реализован он немножко странно, в том смысле, что поддерживается именно NTLM и не поддерживаются никакие другие поставщики безопасности, такие как Negotiate или Kerberos. Кроме того, Outlook Express очень странно проверяет поддержку NTLM на сервере: вместо проверки по CAPA дается команда AUTH без параметров, что противоречит RFC 1939. В Outlook Express NTLM-аутентификация почему-то называется SPA (Secure Password Authentication). Кроме того, он не умеет использовать имя и пароль, введенные в настройках учетной записи сервера, а всегда используются имя и пароль, с которыми пользователь вошел в систему. Поэтому использование SPA целесообразно (и настоятельно рекомендуется), только если почтовый сервер требует доменную учетную запись. Никаких других безопасных протоколов аутентификации Outlook Express не поддерживает. Microsoft Outlook работает с Exchange по собственному протоколу, а для доступа по POP3 используются компоненты Outlook Express.

The Bat поддерживает NTLM-аутентификацию, но при этом используются имя и пароль, указанные в настройках. Так же поддерживаются CRAM-MD5 и APOP.

Что касается почтовых серверов, то практически любой сервер, кроме Microsoft Exchange, поддерживает, как минимум, CRAM-MD5 и DIGEST-MD5. Поддержка NTLM реализована в Communigate Pro и библиотеке Cyrus SASL (используется с Postfix и Courier), однако использование NTLM вне домена Windows неэффективно (обсуждали выше). В Cyrus поддержка NTLM носит экспериментальный характер и по умолчанию отключена. Хуже с поддержкой APOP: он поддерживается в UW-IMAP и Communigate Pro, а вот Cyrus SASL и Courier его не реализуют. Реализовать APOP с применением, например, функций authlib в Courier не сложно (смотри листинг 1), но чтобы засунуть APOP в Courier, необходимо помимо, собственно, обработки команды APOP еще научить выдавать и хранить строку Challenge в угловых скобках в приветствии (фигурирует как param-> banner).