Здравствуйте, DOOM, Вы писали:

DOO> AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
DOO> Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).

Это я понимаю. Я про веб-сервис RSDN говорил, к работе которого Владимир имеет непосредственное отношение

Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Кстати, не напомнишь ту ссылку, где ты бодался по поводу передачи пароля в открытом виде? Что-то не могу найти
DOO>Откопал-таки: http://rsdn.ru/forum/web/3611508.aspx

Автор: krokodil955
Дата: 22.11.09

. Я подозревал, что словосочетание "парольный эквивалент" не часто встречается на rsdn

Еще раз почитал...

— Жуткий город – девок нет, в карты никто не играет. Вчера в трактире спер серебряную ложку, никто даже не заметил – посчитали, что ее вообще не было.

Здравствуйте, andy1618, Вы писали:

A>С большим удовольствием сообщаем,
A>что в основной ассортимент футболок добавлены 6 новых цветов!

Эх если бы только производители футболок это делали... Вырезка из письма от www.superjob.ru (самого цитируемого соц.исследователя рунета) и одного из ведущих HR "агентств":

Здравствуйте, XXX!

Вы разместили свое резюме *** в базе данных сайта Superjob. Последний раз Вы редактировали это резюме ***.

...
Ваши регистрационные данные:
Логин: xxx@yyy.zz
Пароль: @#$%@$
...

Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Эх если бы только производители футболок это делали... Вырезка из письма от www.superjob.ru (самого цитируемого соц.исследователя рунета) и одного из ведущих HR "агентств":

AAV>

AAV>Здравствуйте, XXX!

AAV>Вы разместили свое резюме *** в базе данных сайта Superjob. Последний раз Вы редактировали это резюме ***.

AAV>...
AAV>Ваши регистрационные данные:
AAV>Логин: xxx@yyy.zz
AAV>Пароль: @#$%@$
AAV>...

AAV>

Вот-вот, именно!
Раньше обычно отправлял в ответ стандартное письмо с эпитетами в адрес разработчиков и просьбой больше так не делать.
Теперь же, спасибо автору топика, можно будет отвечать более объёмным и доходчивым текстом ))

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, DOOM, Вы писали:

DOO>> AB>Скажи, а можно сделать что-нибудь с веб-сервисом, чтобы не гонять пароли в открытом виде?
DOO>> Дак способов-то мильон. Даже на уровне HTTP есть, например, аутентификация Dogest MD5 (правда она уязвима для MITM и использовать ее надо только в паре с HTTPS).

AB>Это я понимаю. Я про веб-сервис RSDN говорил, к работе которого Владимир имеет непосредственное отношение

Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.

Проблема в только в том, что на это нужно время

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.
Э-э-э-э... А ведь на RSDN точно была поддержка OpenID — сейчас нет что ли?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.

Хотя, учитывая текущую конфигурацию сервера и реализацию сайта и сервиса, oauth будет предпочтительнее.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>По хорошему — в данном случае, грамотно было бы сделать так: реализовать непосредственно на сайте провайдер openid, завернуть аутентификацию на нем в SSL, а в веб-сервисе использовать уже честный rsdn'овский openid.
DOO>Э-э-э-э... А ведь на RSDN точно была поддержка OpenID — сейчас нет что ли?

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

Здравствуйте, kochetkov.vladimir, Вы писали:

k> Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

SSL не обязательно. ИМХО, достаточно хэша. При чем ломать ничего не надо будет если длина хэша заранее известна и больше максимальной длины пароля. К тому же на клиенте будет правильнее хранить именно хэш, а не открытый пароль. Т.е. без фанатизма.

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, kochetkov.vladimir, Вы писали:

k>> Что-то я не пойму... Как только сайт банка требует больше 10 символов и устанавливает срок действия пароля — так сразу параноидальный. Как только речь заходит о передаче пароля, к аккаунту форума в открытом виде, так сразу извольте навернуть туда SSL, реализовать трехшаговую аутентификацию и бог знает что еще. Зачем?

AB>К тому же на клиенте будет правильнее хранить именно хэш, а не открытый пароль. Т.е. без фанатизма.

На клиенте он не совсем в открытом виде хранится, а в криптосторе. Ибо без фанатизма

AB>AB>SSL не обязательно. ИМХО, достаточно хэша. При чем ломать ничего не надо будет если длина хэша заранее известна и больше максимальной длины пароля.

Ну вот. DO-o-o-o-o-OM! А, они опять...

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

Ты возмутишься, мол как это не даст, когда пароль будет ходить уже не в открытом виде. Мы возразим, что поскольку для аутентификации достаточно хэша, то передача хэша в открытом виде будет полностью эквивалентна передаче пароля в нем же. Ты попросишь привести пример конкретной атаки. Мы будем объяснять, что и в том, и в другом случае будут возможны атаки спуфинга на систему. Тут выяснится, что ты имел ввиду атаки не на систему, а на пользователя. Мы объясним, что предложенная схема снимает ровно одну угрозу: раскрытие содержимого пользовательского пароля, которая актуальна тогда (и только тогда), когда пользователем будет нарушено общеизвестное правило о недопустимости использования одинаковых паролей для тех систем, чья безопасность критична с т.з. пользователя. Во всех остальных случаях, для пользователя это будет абсолютно параллельно, т.о. не совсем понятно, что мешает пользователю прямо сейчас использовать в качестве пароля md5 от какой-нибудь строки. Ты возразишь, что не пользовательское это дело, md5 высчитывать (умалчивая при этом, что все пользователи оффлайн клиентов, в общем-то не очень домохозяйки). Мы пободаемся еще немного и разойдемся до следующего раза.

Правда, мило поговорили?

Здравствуйте, kochetkov.vladimir, Вы писали:

k> Мы объясним, что предложенная схема снимает ровно одну угрозу: раскрытие содержимого пользовательского пароля, которая актуальна тогда (и только тогда), когда пользователем будет нарушено общеизвестное правило о недопустимости использования одинаковых паролей для тех систем, чья безопасность критична с т.з. пользователя.

Вот я именно о ней. Когда получают доступ до одного малозначимого ресурса — это пофиг. Когда получают доступ до некоторой суммы малозначимых ресурсов — становится достаточно неприятно (хоть и не фатально). Можно долго рассуждать о том, что должны и чего не должны делать пользователи, но если избавление от какой-то проблемы стоит всего пары-тройки строк кода, то почему бы и нет (тем более, что что-то более трудоемкое у команды просить бесполезно изначально)?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Ну вот. DO-o-o-o-o-OM! А, они опять...
Я бы только заметил, что Anton Batenev нигде не предложил передавать хэш вместо пароля — он как-то более пространно сказал, а что он имел ввиду — остается загадкой. Я это по дефалту понял как предложение реализовать Challange/Response