WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Перевод выполнен Алексеем Паутовым в рамках некоммерческого проекта RussianLDP (http://www.rldp.ru/). Именно на этом сайте и надлежит искать новые версии, если таковые будут. 34. Аутентификатор plaintext Аутентификатор plaintext может быть сконфигурирован для поддержки аутентификационных механизмов PLAIN и LOGIN, которые оба передают аутентификационные данные в виде открытого (не зашифрованного) текста (хотя и закодированного в base64). Использование открытого текста представляет собой риск для безопасности, настоятельно рекомендую использование SMTP-шифрования (смотрите раздел 38), если Вы используете механизмы PLAIN и LOGIN. Если Вы используете открытый текст, то не должны использовать для SMTP-подключений те же самые пароли, что и для учётных записей пользователей. 34.1. Использование plaintext в сервере При выполнении как сервер, plaintext выполняет аутентификационный тест путём раскрытия строки. Он имеет следующие опции: Имя Использование Тип Значение по умолчанию server_prompts plaintext string† не задана Содержимое этой опции после раскрытия должно быть списком строк подсказок, разделённых двоеточиями. Если раскрытие неудачно, даётся временное отклонение аутентификации. Имя Использование Тип Значение по умолчанию server_condition plaintext string† не задана Эта опция должна быть назначена для конфигурирования драйвера как сервера. Её использование описано ниже. Данные, посылаемые клиентом с командой AUTH, или в ответ на последующие подсказки, являются закодированными base64, и таким образом могут содержать любые значения байтов после расшифровки. Если какие-либо данные доставлены с командой AUTH, они обрабатываются как список строк, разделённых NUL (бинарными нулями), первые три из которых помещаются в переменные раскрытия $auth1, $auth2 и $auth3 (ни LOGIN, ни PLAIN не используют более, чем три строки). Для совместимости с предыдущими релизами exim, значения также помещаются в переменные раскрытия $1, $2 и $3. Однако, использование этих перемнных с этой целью сейчас осуждается, поскольку оно может привети к беспорядку в раскрытиях строк, которые также их используют для других целей. Если в server_prompts находится больше строк, чем передано с командой AUTH, остающиеся подсказки используются для получения дополнительных данных. Каждый ответ клиента может быть списком строк, разделённых NUL-символами. Как только получено достаточное число строк данных, раскрывается server_condition. Если раскрытие принудительно неудачно, аутентификация не пройдена. Любые другие ошибки аутентификации вызывают возврат временного кода ошибки. Если результат успешного раскрытия пустая строка, 0, no или false, то аутентификация неудачна. Если результат раскрытия 1, yes, или true, то аутентификация успешна, раскрывается общая опция server_set_id и сохраняется в $authenticated_id. Для любого другого результата возвращается временный код ошибки с раскрытой строкой в качестве текста ошибки. Предупреждение: Если Вы используете для нахождения пароля пользователя поиск в раскрытии убедитесь, что сделали неудачу аутентификации, если пользователь неизвестен. В конце следующего раздела есть хорошие и плохие примеры. 34.2. Аутентификационный механизм PLAIN Аутентификационный механизм PLAIN (RFC 2595) определяет, что три строки посылаются как один элемент данных (то есть, одна комбинированная строка, содержащая два NUL-разделителя). Данные посылаются как часть команды AUTH или впоследствии в ответе на пустую подсказку сервера. Вторая и третья строки: имя пользователя и соответствующий пароль. Используя одно фиксированное имя пользователя и пароль, как пример, это могло бы быть сконфигурировано следующим образом: fixed_plain: driver = plaintext public_name = PLAIN server_prompts = : server_condition = ${if and {{eq{$auth2}{username}}{eq{$auth3}{mysecret}}}} server_set_id = $auth2 Установка server_prompts задаёт единственную пустую подсказку (пустые элементы в конце списка строки игнорируются). Если все данные прибывают как часть команды AUTH, как обычно и бывает, подсказка не используется. Об этом аутентификаторе извещается в ответе на EHLO: 250-AUTH PLAIN Клиентский хост может аутентифицироваться путём посыла команды: AUTH PLAIN AHVzZXJuYW1lAG15c2VjcmV0 Поскольку тут содержится три строки (больше, чем число подсказок), от клиента не требуется больше данных. Альтернативно, клиент может лишь послать: AUTH PLAIN для начала аутентификации, в этом случае сервер отвечает пустой подсказкой. Клиент должен ответить комбинированной строкой данных. Строка данных закодирована base64, как требуется по RFC. Этот пример после расшифровки <NUL>username<NUL>mysecret, где <NUL> нулевой байт. Она разделяется на три строки, первая из которых пустая. Опция server_condition, в проверках аутентификаторов, что вторые две (username и mysecret) соответствуют. Наличие лишь одного фиксированного имени пользователя и пароля, как в этом примере, не очень реалистично, хотя для маленькой организации с горсткой аутентифицируемых клиентов, это могло бы иметь смысл. Более сложный случай этого аутентификатора может использовать имя пользователя в $auth2 для поиска пароля в файле или БД и, возможно, делать шифрованное сравнение (смотрите crypteq в разделе 11). Вот пример этого подхода, где пароли ищутся в DBM-файле. Предупреждение: Это неправильный пример: server_condition = \ ${if eq{$auth3}{ ${lookup{$auth2}dbm{/etc/authpwd}}}{yes}{no}} Раскрытие использует имя пользователя ($auth2), как ключ для поиска пароля, который, затем, сравнивается с переданным паролем ($auth3). Почему этот пример неправилен? Он прекрасно работает для существующих пользователей, но рассмотрим, что происходит если даётся имя несуществующего пользователя. Поиск неудачен, но поскольку для поиска не даны строки удачи/неудачи, он приводит к пустой строке. Таким образом, чтобы обойти аутентификацию, все клиенты должны предоставлять несуществующее имя пользователя и пустой пароль. Корректный способ написать эту проверку: server_condition = ${lookup{ $auth2}dbm{/etc/authpwd} {${if eq{$value}{ $auth3}{yes}{no}}}{no}} В этом случае, если поиск успешен, результат проверяется; если поиск неудачен, аутентификация - неудачна. Если вместо eq используется crypteq, первый пример, фактически, безопасен, поскольку crypteq всегда неудачна, если второй аргумент пуст. Однако, второй способ написания проверки, делает логику более понятной. 34.3. Аутентификационный механизм LOGIN Аутентификационный механизм LOGIN не задокументирован в каком-либо RFC, но он используется множеством программ. С командой AUTH никаких данных не посылается. Вместо этого имя пользователя и пароль даются раздельно в ответах на подсказки. Аутентификатор plaintext может быть сконфигурирован для поддержки этого, как в этом примере: fixed_login: driver = plaintext public_name = LOGIN server_prompts = User Name : Password server_condition = \ ${if and {{eq{$auth1}{username}}{eq{$auth2}{mysecret}}} \ {yes}{no}} server_set_id = $auth1 Поскольку работает plaintext, этот аутентификатор принимает данные предоставленные с командой AUTH (в нарушение спецификации LOGIN), но, если клиент не предоставляет их (как в случае LOGIN клиентов), строка подсказки используется для получения двух элементов данных. Некоторые клиенты очень следят за точным текстом подсказок. Например, Outlook Express, как сообщают, распознаёт только Username: и Password:. Вот пример аутентификатора LOGIN, использующего эти строки. Он использует условие раскрытия ldapauth для проверки имени пользователя и пароля, путём связи с LDAP-сервером: login: driver = plaintext public_name = LOGIN server_prompts = Username:: : Password:: server_condition = ${if ldapauth \ {user="cn=${quote_ldap_dn:$auth1},ou=people,o=example.org" \ pass=${quote:$auth2} ldap://ldap.example.org/}{yes}{no}} server_set_id = uid=$auth1,ou=people,o=example.org Отметьте использование оператора quote_ldap_dn для корректного квотирования DN для аутентификации. Однако, базовый оператор quote, а не любой из операторов квотирования LDAP, явялется правильным при использовании для пароля, поскольку квотирование необходимо лишь для того, чтобы пароль соответствовал синтаксису exim. На уровне LDAP пароль не интерпретируемая строка. 34.4. Поддержка для иных видов аутентификации Множество особенностей раскрытия строк предоставлены как интерфейс к иным способам аутентификации пользователей. Они включают проверку традиционно зашифрованных паролей /etc/passwd (или эквивалент), PAM, Radius, ldapauth, pwcheck и saslauthd. Для дополнительных деталей смотрите раздел 11.7. 34.5. Использование plaintext как клиента Аутентификатор plaintext имеет две клиентские опции: Имя Использование Тип Значение по умолчанию client_ignore_invalid_base64 plaintext boolean ложь Если клиент получает подсказку сервера, не являющуюся допустимой base64-строкой, оставляется аутентификация по умолчанию. Однако, если эта опция установлена в истину, ошибка в вызове игнорируется, а клиент посылает обычный ответ. Имя Использование Тип Значение по умолчанию client_send plaintext string† не задана Строка задает список разделённых двоеточиями строк аутентификационных данных. Каждая строка независимо раскрывается до отправки на сервер. Первая строка посылается с командой AUTH, дополнительные строки посылаются в ответ на подсказки сервера. До раскрытия каждой строки, значение новой подсказки помещается в следующую переменную $auth <n>, начинающихся с $auth1, для первой подсказки. Этим способом сохраняется до трёх подсказок. Таким образом, подсказка, полученная в ответ на отправленную первую строку (с командой AUTH), может быть использована в раскрытии второй строки и так далее. Если получена недопустимая base64-строка при установленной опции client_ignore_invalid_base64, в переменную $auth <n> помещается пустая строка. Отметьте: Вы не можете использовать раскрытия для создания нескольких строк, поскольку у разбиения приоритет выше и оно происходит раньше. Поскольку аутентификационный механизм PLAIN требует байт NUL (бинарный ноль) в данных, к каждой строке до её отправки применяется дальнейшая обработка. Если в строке есть символы циркумфлекса (^), они все конвертируются в NUL. Если в строке требуется циркумфлекс как данные, символ должен быть удвоен в строке. Это пример клиентской конфигурации, которая воплощает аутентификационный механизм PLAIN с фиксированным именем пользователя и паролем: fixed_plain: driver = plaintext public_name = PLAIN client_send = ^username^mysecret Нехватка двоеточий означает, что весь текст посылается с командой AUTH с символами циркумфлекса, преобразованными в NUL. Подобный пример, использующий механизм LOGIN: fixed_login: driver = plaintext public_name = LOGIN client_send = : username : mysecret Начальное двоеточие означает, что первая строка пустая, таким образом, с командой AUTH никаких данных не посылается. Оставшиеся строки посылаются в ответ на подсказки.

Поиск На сайте В Яндексе