Каморка

Нормальный такой багец.

http://webmail.shaw.ca вводим имя ящика, пароль и к паролю добавляем любые символы... Все равно заходит на ящик.

Anry писал(а):Нормальный такой багец.

http://webmail.shaw.ca вводим имя ящика, пароль и к паролю добавляем любые символы... Все равно заходит на ящик.

Возможно это фича, если он хранит длину пароля и режет все сверх того.

ну подумаешь, какой-нить DES стоит внутри, вот и все больше 8 символов успешно игнорируется. Весь unix живет так N лет и ничего, никто особенно не жужит.

hawk писал(а):ну подумаешь, какой-нить DES стоит внутри, вот и все больше 8 символов успешно игнорируется. Весь unix живет так N лет и ничего, никто особенно не жужит.

Не соглашусь. Что-то мне подсказывает, что ШО радиус сервер с какой-нибудь реляционной базой использует. Десом там точно не пахнет. Радиус использует мд5. Ты спросишь а почему радиус, а я отвечу, потому что так повелось с дайл-ап - универсальный протокол аунтефикации, используемый всеми айэспи и поддерживаемый аппаратурой точек доступа. Впрочем за ШО ручаться не буду.

meser писал(а): Не соглашусь. Что-то мне подсказывает, что ШО радиус сервер с какой-нибудь реляционной базой использует. Десом там точно не пахнет. Радиус использует мд5. Ты спросишь а почему радиус, а я отвечу, потому что так повелось с дайл-ап - универсальный протокол аунтефикации, используемый всеми айэспи и поддерживаемый аппаратурой точек доступа. Впрочем за ШО ручаться не буду.

Согласен, что действительно немного гадание на кофейной гуще. Я просто смотрю по опыту своей конторы и тех систем конкурентов что видел... радиус кстати совершенно не обязан использовать мд5. Crypted-password поле должно жрать как мд5 так и дес.
А как протокол token-value с возможностью добавлять свои токены, никто не запрещает написать вообще свою проверку, Было-бы желание как говорится.

hawk писал(а):

meser писал(а): Согласен, что действительно немного гадание на кофейной гуще. Я просто смотрю по опыту своей конторы и тех систем конкурентов что видел... радиус кстати совершенно не обязан использовать мд5. Crypted-password поле должно жрать как мд5 так и дес.
А как протокол token-value с возможностью добавлять свои токены, никто не запрещает написать вообще свою проверку, Было-бы желание как говорится.

Вот, же спорщик! Нет там des, а только md5! Я хоть и так помню, но вот тебе цитата из RFC 2138:
"... The NAS and RADIUS server share a secret. That shared secret
followed by the Request Authenticator is put through a one-way MD5
hash to create a 16 octet digest value which is xored with the
password entered by the user, and the xored result placed in the
User-Password attribute in the Access-Request packet. See the
entry for User-Password in the section on Attributes for a more
detailed description." http://www.faqs.org/rfcs/rfc2138.html

meser писал(а): Вот, же спорщик! Нет там des, а только md5! Я хоть и так помню, но вот тебе цитата из RFC 2138:
"... The NAS and RADIUS server share a secret. That shared secret
followed by the Request Authenticator is put through a one-way MD5
hash to create a 16 octet digest value which is xored with the
password entered by the user, and the xored result placed in the
User-Password attribute in the Access-Request packet. See the
entry for User-Password in the section on Attributes for a more
detailed description." http://www.faqs.org/rfcs/rfc2138.html

ну уж кто-бы говорил
RFC конечно хороший аргумент... но достаточно много реализаций вполне едят DES, опять же gnu freeradius : http://www.gnu.org/software/radius/manu ... -Auth.html
На самом деле возвращаясь к началу дискуссии, я бы сильно удивился, если бы специально хранили длину оригинального пароля... IMHO либо что-то типа ДЕС, или просто поле в базе N символов и режут при введении. Хотя вроде учитывая что вроде их аппликуха достаточно старая может и что-то очень оригинальное при проверке.

ох, хоть тут бы не слышать уже про етот шэред сикрет...

ок, это работает так: пароль шифруется с сипользованием сикрет. если в пароле недостает
символов или есть лишние - на приеме будет синтакс еррор, т.е. статус - режектед.

из приведенного выше описания бага ясно, что шеред сикрета там вовсе и нет. да,
скорее всего радиус. но весь радиус трафик просто напросто не шифруется. а пароль
трункатится где-то еще дальше. это не недостаток. если никто не может пролезть за
пределы NAS - пофигу как там оно внутре... если конечно, внутренних врагоф нет...

(я не в shaw работаю. всего лишь в RSA )

hawk писал(а): ну уж кто-бы говорил
RFC конечно хороший аргумент... но достаточно много реализаций вполне едят DES, опять же gnu freeradius : http://www.gnu.org/software/radius/manu ... -Auth.html
На самом деле возвращаясь к началу дискуссии, я бы сильно удивился, если бы специально хранили длину оригинального пароля... IMHO либо что-то типа ДЕС, или просто поле в базе N символов и режут при введении. Хотя вроде учитывая что вроде их аппликуха достаточно старая может и что-то очень оригинальное при проверке.

Что-то мы совсем запутались с радиусом. Я говорю про передачу пароля между насом и радиусом сервером, а ты мне толкуешь про способы хранения пароля на радиус сервере. Это две большие разницы.
1. Пароль, передаваемый между насом и радиус-сервером в запросе на аунтефикацию, не шифруется вовсе. Он "прячется" (термин из rfc) в запросе с помощью ксора. Функция для ксора получается грубо говоря из шаред сикрет.
2. На стороне сервера расчитывается таже функция для ксора. Он применятеся к "спрятанному паролю", полученному в запросе и мы имеем открытый текстовый пароль на сервере.
3. Имея имя и пароль осуществляем собственно аунтефикацию.
Где хранится, как хранится и шифруется - дело десятое. Здесь и атрибут Crypt-Password возможен.

Возвращаясь к моему первоначальному утверждению о хранении длины пароля, я признаю, что погорячился. Обрезание там делается, это очевидно, а вот где, дык хоть где, но до самой аунтефикации. Я думаю в радиус-клиенте, прицепленному как cgi к уеб серверу и выполняещему функцию нас.

упс. сбойнуло.