— SATtva (14/02/2007 20:08)   

Насколько это серьезно и жизнеспособно?

Ну, там в комментариях замечания высказаны. Это не слишком элегантная схема и в любом случае уязвимая. Главная проблема — риск подмены модуля javascript при его закачке пользователем. В принципе, поскольку скрипт открыт, пользователь может самостоятельно сверить его правильность, просмотрев код, но делать это придётся каждому, а многие ли на это способны?

И не будет ли уважаемый SATtva против?

Если Вы видите в этом перспективу, ничуть не буду. Можете даже опубликовать где-нибудь для свободного доступа, но и против коммерческого использования я не стану возражать. И, тем более, против образовательного. В общем, дело Ваше. Только не забудьте отметить все ограничения подобной схемы.

— Гость (14/02/2007 23:18)   
Спасибо за ответ и разрешение использования Вашей идеи. Если реализация выйдет действительно хоть сколько-нибудь приминимой на практике, то будет иметь свободное распространение.

— Alex_B (21/02/2007 11:56)   
Пилотная версия реализации протокола готова. Если кто-нибудь этим заинтерисуется выложу её с подробными коментариями и описаниями.
Буду благодарен за критику.
(выкладывать бесполезный для пользователей материал – засорять ресурс, поэтому я не делаю этого сейчас)

Спасибо.

— SATtva (22/02/2007 11:20, исправлен 03/06/2007 20:35)   
Отчего же? Создайте в разделе черновиков^[link1] страницу и опубликуйте там в виде исходного кода. Подобного вида^[link2] публикации у нас уже есть. В любом случае кто-нибудь может найти там что-то для себя полезное.

— Гость (22/02/2007 12:43)   
SATtva ваша система защиты от mitm атаки слаба. Она базируется на том, что злоумышленик будет пытаться использовать перехваченые днные со своего ip, но злоумышление способный перехватывать трафик жертвы вполне может использовать ее ip.
Единственное нормальное рещение – SSL на всем сайте. Я могу предоставить хостинг для этого сайта с ssl, если вам это нужно.

— Alex_B (22/02/2007 18:35, исправлен 03/06/2007 20:35)   
Добавил страницу по адресу /Разработки/HttpАвторизация^[link3]

Буду благодарен за критику и предложения как по самому коду так и по протоколу. Хотелось бы сделать применимый на практике протокол.
Ищу единомышленников.

— SATtva (22/02/2007 19:23)   
Гость, если я не ошибаюсь, TCP имеет некоторые контрмеры от простой подстановки IP-адресов в исходящих пакетах. В обычном случае, получатель просто будет отвечать на этот же подставной адрес. Конечно, если противник контролирует значительный сегмент сети Анны (скажем, если является её интернет-провайдером), атака может сработать. Если же нападающий — просто зловредный прокси-узел на маршруте трафика Анны, ему это будет не по силам.

В целом, Вы правы, конечно, допущение с моей стороны было смелое. На эту идею меня невольно воодушевил unknown с высказанными как-то опасениями, что пароль для доступа к сайту может быть перехвачен преступным Tor-узлом. Для подобного узкого случая схема вполне пригодна (если не рассматривать другие её проблемные места, уже отмеченные выше).

За предложение хостинга спасибо, но мы уже набегались. Отсутствие SSL сейчас упирается в недостаток моего времени для доработки движка, чтобы ввести поддержку защищённых сессий.

— Гость (23/02/2007 08:26)   
SATtva насколько я понимаю, для защиты от злоумышлегого прокси такой протокол неприменим вобще, так как он не позволит самому пользователю произвести соединение. Вы сами писали:

В случае, если пользователь сам указывает ip прокси для разрешения с него соединений, то теряется весь смысл защиты от mitm. Если не указывает, то сам не сможет через прокси работать.
В случае, если пользователь работает напрямую, то изменение трафика возможно только на маршрутизаторе, ну а для него не проблема использовать ip пользователя для создания своих соединений.

— SATtva (23/02/2007 10:19)   
Вот наглядное преимущество открытой разработки. Запороли нежизнеспособную схему. И поделом ей. :-)

— Alex_B (23/02/2007 11:32)   
Хоть какая-нибудь область применения может быть?

— SATtva (23/02/2007 15:11, исправлен 23/02/2007 15:15)   
Боюсь, только защита пароля от раскрытия. Но чтобы это полностью работало, придётся доработать схему для поддержки защищённой регистрации. Проблемой здесь останется то, что при активном вмешательстве противник сможет изначально зарегистрировать свой пароль вместо пользовательского. Решить это без применения асимметричной криптографии не удастся.

Кстати, мне где-то попадалась компактная реализация части протокола OpenPGP на javascript; тормозная, но в целом довольно неплохо. Можно покопать в этом направлении.

— Alex_B (26/02/2007 15:56)   
Спасибо за направление, попробую разобраться.

А есть ли координальные отличия обсуждаемой идеи от протокола CHAP?
http://wiki.satgate.net/index.php/CHAP

— SATtva (26/02/2007 19:37)   
Ну, CHAP — это вообще основа множества протоколов аутентификации без раскрытия секрета. Так что, можно сказать, эта идея — очередное его расширение.