Если переделать здесь запрос  user_query на следующий

Он не ругается.

Проблема решена!

AlfaStriker в продолжении данной темы задам вопросик если позволите : как использовать зашифрованные пароли вместо plain ? (на примере Outlook не получается настроить что то другое) 

С этого места можно поподробней ?

nik222
Для того чтобы хранить пароли в формате MD5 надо:
Открыть файл /etc/dovecot/dovecot-mysql.conf
В нем найти и изменить строчку на:

default_pass_scheme = MD5-CRYPT

Потом открыть главный конфигурационный файл Exim - /etc/exim/exim.conf и поменять секции авторизации:

auth_plain:
driver = plaintext
public_name = LOGIN
server_prompts = Username:: : Password::
server_condition = "${if crypteq{$2}{${lookup mysql{SELECT `password` FROM `mailbox` WHERE `username` = '${quote_mysql:$1}'}}}{yes}{no}}"
server_set_id = $1

auth_login:
driver = plaintext
public_name = PLAIN
server_condition = "${if crypteq{$3}{${lookup mysql{SELECT `password` FROM `mailbox` WHERE `username` = '${quote_mysql:$2}'}}}{yes}{no}}"
server_prompts = :
server_set_id = $2

auth_cram_md5:
driver = dovecot
public_name = CRAM-MD5
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1

Далее требуется открыть конфигурационный файл PostfixAdmin - /var/www/html/postfixadmin/config.inc.php
В этом файле надо найти и поменять значение строчки:

$CONF['encrypt'] = 'md5crypt';

После настройки Exim, Dovecot и Postfixadmin надо перезапустить демон Exim и Dovecot:

# service exim restart

# service dovecot restart

Если есть старые учетные записи в которых пароль хранится открытым текстом, надо заного пересоздать эти учетные записи.

Вообще-то пароли уже по умолчанию создаются в MD5.
Это прямо видно в файле config.inc.php выше.

Для этого надо использовать шифрования SSL/TSL.
Настройка этого есть в сети.

дело в том, что злоумышленник может получить доступ к базе данных, и КО ВСЕМ паролям на вашем сервере.
Однако, если злоумышленник получит все хеши, а не все пароли, то это ему ничего не даст. Суть в том, что можно из пароля вычислить хеш, но обратное преобразование невозможно (только полным перебором, что для пароля из 8+ символов невозможно на сегодня).

если злоумышленник перехватил именно пароль, то он может им воспользоваться. Однако, имея хеш пароля, ничего сделать нельзя. В том случае, конечно, если этот хеш вычисляется сервером. Последнему нужен именно пароль, а не хеш, который сервер вычисляет самостоятельно, и сравнивает его со своим хешем из БД. У одинаковых паролей одинаковые хеши, потому хранить пароли НИКОГДА не нужно.

У этой схемы имеются две уязвимости:

1. действительно, можно перехватить пароль. Однако, выловить пароль не так уж и просто, нужен полный доступ хотя-бы к одному из транзитных маршрутизаторов
2. можно воспользоваться радужными таблицами, которые можно приготовить заранее, а затем быстро взломать пароль по его хешу. К счастью, для защиты можно добавить к паролю случайную соль, которая приведёт к тому, что таблица не сработает.

и что помешает злоумышленнику проделать точно такую-же операцию? К сожалению, если юзер не может доверять серверу, а сервер не может доверять юзеру, то данная схема НЕ сработает. Такие дела.
Но и тут есть выход - нужно привлечь какую-либо третью сторону, которой доверяет и клиент, и сервер. Т.е. серверу необходим сертификат, подписанный третьей стороной. В этом случае, клиент может проверить сертификат сервера, и будет уверен в том, что данный сервер не является подставой (fake). В противном случае клиент может послать свой пароль/дайджест/хеш/хитромудрый ключ на 100500 бит не на сервер, а прямо злоумышленнику, со всеми вытекающими.

ответ - да. В открытом виде.

зависит от того, ЧЕГО вы желаете добиться. Попробуйте для начала настроить TLS шифрование. Отправная точка: http://ru.wikipedia.org/wiki/TLS
Но ещё раньше решите, а оно вам ДЕЙСТВИТЕЛЬНО надо? Лично я и так обхожусь (дык неуловимый Джо же!)

могут. Используя TLS.
Передавать хеш пароля а не сам пароль не имеет никакого смысла - если сервер принимает хеш, то злоумышленник может его перехватить и им воспользоваться. Кстати, почтовый клиент НЕ передаёт пароль на почтовый сервер. Обычно клиент передаёт почту на какой-нить промежуточный сервер, а с него почта идёт дальше проходя несколько промежуточных узлов. По этой причине ваш сервер вряд-ли будет работать с клиентом напрямую.

ИМХО шифровать почту/почтовые пароли не имеет особого смысла. Если сообщение секретное, или важно доказать, что вы это действительно вы, используйте GnuPG шифрование и ЭЦП. (жаль, что многие люди пугаются цифровых сигнатур, которые я леплю в каждой мессаге )

Вопрос - как? Особенно, если бэкапы хранятся правильно. Тогда для того, чтобы получить доступ к базе, которая хранит пароли, надо знать пароли доступа к базе. Если нет этого знания - как получить доступ к базе? Или мы храним парольную информацию в базе, которая отвечает первому встречному на его select all password?  :-)

Заблуждение. Нет принципиальной разницы что передавать серверу - перехваченный пароль или перехваченный хэш пароля. Если актуальна угроза перехвата протокола аутентификации, то одинаково опасно пользоваться как плайн-паролями, так и потоянными их хешами.
Простой и наглядный пример - протокол аутентификации в POP3. POP3-сервер ждет от клиента дайджест пароля. Что мешает нарушителю этот дайджест перехватить и ввести его от имени пользователя? Сам, когда изучал почтовые протоколы телнетом ходил на свои РОР-сервера и дайджесты паролей вставлял из клипборда. Так что, по уровню устойчивости при перехвате, что простой пароль, что его дайджест - одинаково ненадежно. Никто не станет восстанавливать исходный пароль. Применять будут именно дайджест. Передача же дайджестов паролей - это создание иллюзии безопасности.

Это нормальная рабочая схема. При перехвате процедуры аутентификации у нарушителя нет знания одного секрета - знания пароля пользователя. Поэтому нарушитель не может повторить эту процедуру. Нарушитель может перехватить случайную соль, посланную с сервера и ответ юзера, смешанный с этой случайной солью. То есть тоже случайное число. Ни пароли, ни их дайджесты при этом по сети не передаются. Они используются для вычисления новой случайности на стороне клиента и сервера. Из этого случайного числа восстановить неслучайный пароль, чтобы проделать ту же операцию и зайти от имени легального юзера на реальный сервер - не слишком возможно.
Ну а рисовать сервер до неотличимости схожий с реальным (то есть расматриваем ситуацию, когда не доверяем серверу) - это слишком перебор. Я не могу отнести эту угрозу к реальным (при аутентификации с со случайной солью онли). Это можно логин-страницу вконтакта или одноклассников подставлять. Но там и случайной соли в аутентификации нет. Так что информацию о паролях собрать можно. А там, где используется соль - ничего не соберешь. 

Это тоже решение. Но реально - если не впадать в паранойю - перебор.

Ничем не лучше. Какая разница, что утечет, сам пароль или его хэш, если сервер пускает к себе по полученному от юзера (или кого угодно) паролб или хэшу? Утекут хэши с сервера и будет нарушитель их подставлять (или иначе использовать) в свое полное удовольствие...

Совершенно нет. Неправильно. Нет там, в этой схеме никаких криптографических (за исключением вычисления хэша, который не слишком криптография, так как нет там секрета) алгоритмов, никаких сертификатов (я понимаю этот термин исключительно в рамках ассиметричной криптографии, в рамках ЭЦП и всего, что на этой базе построено). Соль этого алгоритма - в передаче клиенту _случайной_ соли, случайного значения, синхронного вычисления клиентом (хеша пароля, хеша конкатенации случайной соли и хэша пароля) и сервером (хеша конкатенации случайной соли и хэша пароля, хранящегося на сервере) и равнения на сервере того, что вычислил клиент с тем, что вычислил сервер. При этом ни пароли, ни их хэши по сети не передаются, передаются только случайные (каждый раз новые) значения. Кстати, это алгоритм аутентификации в сетях NovellNetware.

Мы сознательно переходим от проблемы надежной аутентификации на сервере (каких либо приложений) к проблеме защиты почтовых сообщений? Гарантированности их целостности, авторства и конфиденциальности? Я ни разу не обсуждал почту и если и упомянул POP3-сервер, то лишь как пример иллюзии надежной аутентификации юзера (с помощь. хэша пароля) на нем.

Соль не может и не должна быть постоянной. Соль должна быть исключительно случайным значением. Тогда она сыграет свою рояль. Иное - иллюзия.

В этом - полный консенсус. При полном понимании собеседниками, что пароль доступа к почтовой службе это одно, а ЭЦП и шифрование почтового
сообщения - совсем иная дисциплина к паролям доступа к почтовой службе не имеющая никакого отношения.

Про сейфовые комнаты в курсе?

Lupo Alberto: Нарядно, конечно, но... в «личку», если кто заинтересуется.
ну как-то так..

та не, мы с неё и начали.