LINUX.ORG.RU

Ответ на: комментарий от Pinkbyte

То, что надо. 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.

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

Tanger ★★★★★
() автор топика
Ответ на: комментарий от Tanger

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

ventilator ★★★
()
Ответ на: комментарий от Tanger

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от Tanger

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

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

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

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

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

Ты писал:

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

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

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

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

anonymous
()
Ответ на: комментарий от DonkeyHot

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

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

anonymous
()
Ответ на: комментарий от anonymous

Враньё.

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

Macil ★★★★★
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от anonymous

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от anonymous

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от Macil

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

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

berrywizard ★★★★★
()

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

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

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

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

AGUtilities ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.