[ejabberd] Пароль в базе хранится в открытом виде

буду краток - вот мнение авторов ежа: http://www.ejabberd.im/plaintext-passwords-db

То, что надо. http://nullable.de/using-salted-hashed-password-in-your-ejabberd

Я только не понял связь между

storing passwords in plaintext limits the security of communications.

и

it is more secure to send passwords encrypted over the network, and store them in plaintext on the database, than sending the passwords in plaintext over the network and store them encrypted on the database.

Почему нельзя и по сети в зашифрованном виде и в бд в зашифрованном?

Не знаю как в джаббер авторизация происходит, но например для CHAP авторизации нужно хранить именно чистые пароли, а не хеши.

потому что если нужен необратимый алгоритм шифрования, тогда его придется использовать везде. А разные методы авторизации(plain text, LDAP, SQL) могут использовать разные шифры. И если SQL и plain text файлам по барабану как зашифрован пароль, то вот насчет LDAP я не уверен

А разные методы авторизации(plain text, LDAP, SQL) могут использовать разные шифры.

Я смотрю ты про в области шифрования. Расскажи, пожалуйста, какой шифр используется в «plain text» авторизации?

Я смотрю ты читаешь плохо... Я говорил не про plain text авторизацию, а про хранение пользователей/паролей в plain text файлах. Улавливаешь разницу?

иначе какой шифрование используется для полей пароля в SQL? В общем случае: да какое задашь(в postfix, к примеру, можно и plain и md5), такое и будет. Другое дело как к этому зашифрованному полю подвязать алгоритмы, также использующие шифрование пароля, которым НУЖНО знать оригинальный пароль(CHAP для VPN или CRAM-MD5 для почты). Вот и приходится в таких случаях хранить пароли в открытом виде, что не Ъ конечно, согласен...

а в plain text МЕТОДЕ авторизации используется, ВНЕЗАПНО, plain text. То есть незашифрованное имя пользователя и пароль. Всегда ваш, К.О.

Почему нельзя и по сети в зашифрованном виде и в бд в зашифрованном

Хранение необратимо зашифрованного пароля требует передачи его от клиента. Передача открывает возможность перехватывать пароли неосторожных(коих большинство) пользователей подставляя им фиктивный сервер, _или_ проломав настоящий.

Доступ к незашифрованному паролю позволяет применять схемы проверки, исключающие передачу оного, т.ч. остаётся только 1 направление атаки, плюс хорошие возможности(хотя я ещё не видел реализации) его прикрыть.

Следовательно второе безопаснее.

А разные методы авторизации(plain text, LDAP, SQL) могут использовать разные шифры.

Я смотрю ты про в области шифрования. Расскажи, пожалуйста, какой шифр используется в «plain text» авторизации?

Я смотрю ты читаешь плохо... Я говорил не про plain text авторизацию, а про хранение пользователей/паролей в plain text файлах. Улавливаешь разницу?

Ты писал:

разные методы авторизации(plain text,

могут использовать разные шифры.

Улавливаешь?

«Plain text» шифр. Забавно. Да.

Хранение необратимо зашифрованного пароля требует передачи его от клиента.

Враньё.

_или_ проломав настоящий.

... злоумышленник получит все пароли, так как они хранятся в plain text. Как это можно считать секьюрной фичей?

Враньё.

Вау! Благородный дон открыл новые области криптографии? Так поделитесь же, мы все в нетерпении.

Нужно использовать шифрование типа «plain text» (С) автор выше

пароль при авторизации в plain text файле может иметь любой шифр. Или нет?

нужно использовать хранилище для паролей типа plain text (c)

проломав настоящий...злоумышленник получит все пароли,

Так он их и в первом случае получит, клиенты же ему его сами передадут.

Могу предположить. Сервер берёт хэш [соль+хэш пароля], передаёт клиенту соль, ждёт от него хэш [соль+хэш пароля] (клиент из пароля вычисляет хэш). Если присланное совпадает с имеющимся вычисленным хэшем, у клиента есть правильный пароль.

Понятно, схемка так себе, но клиент сам пароль на сервер не передавал.

шифрования паролей нет и у некоторых транспортов.

но всё таки, так ли оно нужно? ведь не шифрованные пароли - проще восстанавливать, на пример.

да и потом, есть не мало модулей, способных перехватить xmpp сообщения на уровне сервера, так что грамотному админу, не составит особого труда.

тут уж, приходится уповать на честность обслуживающего персонала. по этому, я предпочитаю свой сервер :)